RFC: bsd.port.mk needs some changes around plist processing

Matthias Andree mandree at FreeBSD.org
Wed Feb 19 09:38:44 UTC 2014


we've recently seen that the docbook ports were broken, and while the
ports now build, they still cause leftover directories;

Details in PR 186882:

Sample log from Tinderbox:

Background: the ports - by way of textproc/docbook/bsd.docbook.mk -
add port documentation to TMPPLIST, and adds a few @dirrm-like instances
to TMPPLIST, too.  In practice, this does not work due to several
ordering issues in bsd.port.mk:

1. TMPPLIST stuff added from do-install is *not* subject to the
@dirrmtry and related processing that generate-plist does.  Stuff added
from pre-install would be, however.

This processing, for instance, changes @dirrmtry D to @unexec rmdir D ||
: for pre-pkgNG hosts.

The cause is that generate-plist runs between pre-install and do-install.

2. post-stage stuff is currently executed *after* stage-qa, so stage-qa
does not check the final state of the stagedir, but an intermediate
state.  In particular, if post-stage were used to fix TMPPLIST, stage-qa
would already have complained about plist problems that are no longer
present when the overall "stage" target is reached.

Consequence: The port in fact cannot add @dirrm to TMPPLIST without
reimplementing several bsd.port.mk targets or without causing bogus

It is certainly possible to work around all this with a POST-DEINSTALL
target, but I propose that we fix the framework instead.

I propose that bsd.port.mk:

F1. moves stage-qa until after post-stage so that stage-qa validates the
final STAGEDIR contents.

F2. adds a late-plist target so that a port can add clean-up material to
TMPPLIST *after* everything that is derived from variables such as
PORTDOCS, PORTEXAMPLES.  This should be really late in the process,
possibly only before the fix-plist-sequence.

F3. the postprocessing with REINPLACE_CMD that, for instance, translates
@dirrmtry, be
(a) split out from generate-plist and
(b) run *after* late-plist,

so that ports can just start using the pkgNG directives (such as
@dirrmtry) that pkg_create does not understand.  Possibly before the
fix-plist-sequence target.

F3 is particularly important so that we don't add backwards kludges (as
mat@ had to do for the docbook/bsd.docbook.mk) that we will have to
clean up later when pkgNG is the only supported tool.

Now, I've tried to figure out how the whole bsd.port.mk rigging works,
took a few stabs at it, and have found myself lost, so I cannot propose
code or provide patches; someone who is more acquainted with the
bsd.port.mk sequencing and target innards should do that.

I'll be happy to help with testing, and fixing the docbook ports, on
pkgNG as well as on pkg_create/pkg_add systems.

Any takers?


More information about the freebsd-ports mailing list