From owner-freebsd-ports@FreeBSD.ORG Wed Feb 19 09:38:44 2014 Return-Path: Delivered-To: ports@freebsd.org Received: from mandree.no-ip.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0F6A290; Wed, 19 Feb 2014 09:38:43 +0000 (UTC) Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 1AE9023CE92; Wed, 19 Feb 2014 10:38:42 +0100 (CET) Message-ID: <53047BA1.8020401@FreeBSD.org> Date: Wed, 19 Feb 2014 10:38:41 +0100 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: FreeBSD Ports Mailing List Subject: RFC: bsd.port.mk needs some changes around plist processing X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Mathieu Arnold , Baptiste Daroussin , Gabor Kovesdan , portmgr@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 09:38:44 -0000 Greetings, 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 warnings. 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? Cheers, Matthias