From owner-svn-ports-head@FreeBSD.ORG Sun Mar 23 18:31:56 2014 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C687F230; Sun, 23 Mar 2014 18:31:56 +0000 (UTC) Received: from apnoea.adamw.org (apnoea.adamw.org [204.109.59.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A9E17F8; Sun, 23 Mar 2014 18:31:56 +0000 (UTC) Received: from [192.168.2.1] (dhcp-108-170-169-46.cable.user.start.ca [108.170.169.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by apnoea.adamw.org (Postfix) with ESMTPSA id 36AF0121CB8; Sun, 23 Mar 2014 14:31:55 -0400 (EDT) From: "Adam Weinberger" To: "Bryan Drewery" Subject: Re: svn commit: r348866 - head/ports-mgmt/poudriere-devel Date: Sun, 23 Mar 2014 14:31:52 -0400 Message-ID: <893AE220-E1DA-4F3A-93E1-D7820B3C5FC4@adamw.org> In-Reply-To: <532F23DD.5020008@FreeBSD.org> References: <201403231540.s2NFeBjV061182@svn.freebsd.org> <9753239EA269BEFE3D11835F@atuin.in.mat.cc> <532F08B7.8010602@FreeBSD.org> <79C5E9B2B1255838D240E362@atuin.in.mat.cc> <532F09E2.6090309@FreeBSD.org> <532F23DD.5020008@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.7.2r4025) Cc: Mathieu Arnold , svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:31:56 -0000 On 23 Mar 2014, at 14:11, Bryan Drewery wrote: > On 3/23/2014 12:49 PM, Adam Weinberger wrote: >> On 23 Mar 2014, at 12:20, Bryan Drewery wrote: >> >>> On 3/23/2014 11:18 AM, Mathieu Arnold wrote: >>>> >>>> >>>> +--On 23 mars 2014 11:15:51 -0500 Bryan Drewery >>>> >>>> wrote: >>>> | On 3/23/2014 11:11 AM, Mathieu Arnold wrote: >>>> |> +--On 23 mars 2014 15:40:11 +0000 Bryan Drewery >>>> >>>> |> wrote: >>>> |> | .include >>>> |> | >>>> |> | +post-install: >>>> |> | .if ${PORT_OPTIONS:MZSH} >>>> |> | -PLIST_FILES+= share/zsh/site-functions/_poudriere >>>> |> | -PLIST_DIRSTRY+= share/zsh/site-functions >>>> |> | -PLIST_DIRSTRY+= share/zsh/ >>>> |> | -.else >>>> |> | -MAKE_ENV+= NO_ZSH=yes >>>> |> | + @${MKDIR} ${STAGEDIR}${PREFIX}/share/zsh/site-functions/ >>>> |> | + ${INSTALL_DATA} ${WRKSRC}/completions/zsh/_poudriere \ >>>> |> | + ${STAGEDIR}${PREFIX}/share/zsh/site-functions/ >>>> |> | .endif >>>> |> >>>> |> I think you could do without the include and always install the >>>> file. >>>> |> >>>> | >>>> | What? >>>> >>>> Replace: >>>> >>>> .include >>>> >>>> post-install: >>>> .if ${PORT_OPTIONS:MZSH} >>>> @${MKDIR} ${STAGEDIR}${PREFIX}/share/zsh/site-functions/ >>>> ${INSTALL_DATA} ${WRKSRC}/completions/zsh/_poudriere \ >>>> ${STAGEDIR}${PREFIX}/share/zsh/site-functions/ >>>> .endif >>>> >>>> With: >>>> >>>> post-install: >>>> @${MKDIR} ${STAGEDIR}${PREFIX}/share/zsh/site-functions/ >>>> ${INSTALL_DATA} ${WRKSRC}/completions/zsh/_poudriere \ >>>> ${STAGEDIR}${PREFIX}/share/zsh/site-functions/ >>>> >>>> The package won't register the file if the option is disabled, and >>>> it >>>> removes the need for make to parse bsd.port.mk twice. >>>> >>> >>> And then there is a stage orphan. >>> >>> No. >> >> Staging only installs things listed in the plist. If the ZSH option >> is >> enabled, that file is in the plist. Stage orphans are files that >> never >> get installed, no matter which options are selected. > > Right, there are no *leftovers*, but there are *orphans*. Files which > are in stagedir and never installed. I invented the whole idea of > stage > orphans and checking for them in poudriere, before it was a target in > ports. Installing a file to the stagedir and never installing in the > package creates a fatal error in poudriere as an orphan. Leaving > false-positive orphans creates a very hard to maintain situation. > Someone will come along in the future and update, see orphans, and not > know if they are new or not. The point is to find files you forgot to > add to the plist. > > Sorry but the stagedir cannot have orphans in it, it's not intended > for > that. It's intended to make leftovers impossible and allow packaging > as > non-root. Leaving untracked files in there is a big red flag that your > package is missing something. You must handle them either by not > installing them or by removing them. > > People are missing this point. You must keep the stagedir clean if you > want to pass poudriere testing. Many people have been giving incorrect > advice on how to treat the stagedir and it's going to be a big problem > once we start doing daily QAT/poudriere on the tree to find leftovers > and orphans. Right now orphans are going unfound because QAT/tinderbox > doesn't check for orphans. That is a big problem right now. When > staging > a port, you now have no idea if there are files missing from plist if > you are depending on QAT. > > I really wish people would stop giving the awfully incorrect advice > here. People are making it into some kind of style or opinion matter, > but it's simply not the case. > > There are ideas and plans to only consider an orphan as something that > is not in any plist (for subpackages), but we don't have subpackages > yet. So we are left with keeping the stagedir clean. The ability to dramatically simply a port's Makefile and let simple plist %%OPTIONS%% figure out the rest is an incredibly powerful, useful, and advantageous thing. I am having trouble understanding why we should give it all up so "to pass poudriere testing." Ports work perfectly right now. They install exactly what we intend them to install, and it works perfectly for users. If poudriere is unhappy, then it seems to me that the problem is with poudriere. Maybe it wasn't how you originally envisioned that staging would work. But people have adopted it not because of "awfully incorrect advice," but because that's how we want it to work. Hitachi doesn't recall Magic Wands just because they wanted a back massager. # Adam -- Adam Weinberger adamw@adamw.org http://www.adamw.org