On Sun, Jun 07, 2020 at 12:16:01PM +0200, Landry Breuil wrote:
> On Tue, Jun 02, 2020 at 06:24:41PM -0400, Chris Bennett wrote:
> > The above errors Landry had (and I also had) only occur if pgtap is
> > installed first. The ports documentation suggests an easy fix for that
> > by setting PGUSER=postgres this way: gmake installcheck PGUSER=postgres
>
> Yeah, but that doesnt work - have you read the testing framework in
> postgresql.port.mk ? Setting PGUSER=postgres (or USER!=whoami and then
> PGUSER=${USER} in TEST_ENV doesnt help, the db will still belong to
> ${USER} (because that's how the testing framework work) and afaict the
> tests hardcode 'postgres'.
Since exporting "PGUSER=postgres" happens as part of the
MODPOSTGRESQL_TEST_TARGET adjusting it in, for example, TEST_ENV,
doesn't work. Instead we need to adjust PGUSER to be ${USER} later in
MODPOSTGRESQL_TEST_CMD so it takes effect and we can get the user the
test expects and everything is awesome.
(also specify a PGDATABASE as that's the only one that exists)
MODPOSTGRESQL_TEST_CMD = ${LOCALBASE}/bin/psql -c 'CREATE EXTENSION pgtap;' && \
PGUSER=${USER} PGDATABASE=postgres \
${MAKE_PROGRAM} ${ALL_TEST_FLAGS} -f ${MAKE_FILE} ${TEST_TARGET}
Under the hood `pg_prove` lets `psql` default to the PGUSER, and because
we are using the "trust" authmethod, that lets us log in as ${USER} just
fine. I have no idea why the database is owned by ${USER} and not
${PGUSER} since AFAICT the only user who should exist is postgres and
that is who we are logged in as when the db gets created. Unless it's
testing the "postgres" db that got created during initialization and not
the one it creates, I didn't read the tests well enough to figure that
out.
I also had to rm patches/patch-sql_pgtap-static_sql_tmp as it couldn't
find that file in my extract, not sure what is going on there, but tests
passed without it. Is the port I have out of date?
p5-TAP-Parser-SourceHandler-pgTAP's COMMENT starts with an uppercase
letter, not sure if that's on purpose or not, AFAIU they don't normally,
although portcheck doesn't seem to complain.
In any case, both of these ports seem perfectly reasonable to import.
OK afresh1@
