From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0FF921381F3 for ; Fri, 19 Apr 2013 16:29:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87261E0A6B; Fri, 19 Apr 2013 16:29:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DDDA5E0A6A for ; Fri, 19 Apr 2013 16:29:54 +0000 (UTC) Received: from [192.168.1.4] (pool-71-245-176-92.pitbpa.fios.verizon.net [71.245.176.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id AEE9433DF29 for ; Fri, 19 Apr 2013 16:29:53 +0000 (UTC) Message-ID: <5171718E.3040508@gentoo.org> Date: Fri, 19 Apr 2013 12:32:14 -0400 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130406 Thunderbird/17.0.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 To: gentoo-catalyst@lists.gentoo.org Subject: Re: [gentoo-catalyst] [PATCH 0/2] Blacklisting binary packages References: <20130309121023.GE26574@odin.tremily.us> <517150A6.8020207@gentoo.org> <20130419161816.GD32441@odin.tremily.us> In-Reply-To: <20130419161816.GD32441@odin.tremily.us> X-Enigmail-Version: 1.6a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 498500e9-8f79-442d-a949-64eadea26ef0 X-Archives-Hash: 35c563be2e3ec67c46e7191203963d8a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/19/2013 12:18 PM, W. Trevor King wrote: > On Fri, Apr 19, 2013 at 10:11:50AM -0400, Rick "Zero_Chaos" Farina wrote: >> On 04/16/2013 03:42 PM, W. Trevor King wrote: >>> From: "W. Trevor King" >>> >>> The current approach to avoiding problems due to stale binary packages >>> with untracked ABI dependencies is to disable binpkg use during >>> troublesome sections of the build (e.g. seed updates). I think that a >>> cleaner solution would be to use a configurable spec option >>> blacklisting binpkgs for troublesome packages. For example, in a >>> stage1 with update_seed enabled, the Portage emerge (before the seed >>> update) has: >> >> This needs to remain optional. > > It is optional. Just set `binpkg_blacklist` explicitly to an empty > string if you don't want to blacklist the default packages (currently > only two). > >> I'm not going to nack a patch that some people may find useful but >> in my personal opinion this is a terrible solution that should not >> be used. We need to find a way to rebuild packages as needed (like >> EAPI 5) not force a rebuild everytime. > > Agreed, but in the absence of one of the following: > > * a tree full of EAPI-5+ packages that correctly use ABI sub-slotting > (if I live long enough to see this, I'll be very happy ;), > * local overlays fixing ABI sub-slotting (maintained by folks without > much experience in the packages in question?), or > * Portage tweaks to work around packages that don't use EAPI-5+ (or > that do, but don't use ABI sub-slots appropriately). > > I'm fairly confident that none of those are happening in the next six > months, and there seems to be agreement that catalyst needs some sort > of local hack to work around the problem until one of the real > solutions lands. > > The `binpkg_blacklist` option lets you name (on a per-package level) > troublesome packages that get ABI sub-slots wrong (or don't even try). > I think that this approach will force *fewer* rebuilds than the > current approach (from e7ea409 and 6c0a577) which blacklists > everything from the seed update. > > Another (non-exclusive) possibility is to put a big warning on the > binpkgs option [1] and leave it up to folks to use at their own risk. As I already stated, I have no issue allowing this into the code base as one option people can use. It may be a good idea to make this patch depend on your other patchset which fixes up some of the documentation and adding more detailed documentation....unless you already did that and I'm not paying attention. Thanks, Rick > > Cheers, > Trevor > > [1]: http://mid.gmane.org/cover.1366075786.git.wking@tremily.us > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRcXGOAAoJEKXdFCfdEflKy8sP/jjNADHnnzt2vl8suWHt3LlL pKuyKwjN9GDdhQJrzLZKYmQZNEFfT+GYUq+Z6zTpuR2fE7+d6SCJZDOOIpjO/cMh MUMxn+E49rwMo3IPX/ZuaXAAH0OINM2NFg5paX1jorN+WRXmKkvAJQbbRuBAWSBo OxKz7XsldEjELgCch5/yJH7as8mITFqcheXVMXLOS6xYKCbSHOpnP2s6+KMLlon5 Tw/DNviKvGOGQtLLd4ZWzqic0ElbQUmZIBNpWxODIbfmb2dH46/Xa2pybUOxqm+6 VVhrDxNbEaHNirNxTx3DrWyaeg6Dz/KSEoWHSOYy8DYgg+sIFWrC5RLHg21uWdhU rGtGnj61hjjuKNsQlzyhFRH7Mxn8fOcktVFfbW1l2Mnvqr0zJbuKeyupt/vpyVHH bTZL0PBNSPX9YrMQD3wrpW4UxUMBLQCfAfSmNRsb3vtXXjGnI2Q7bmLQnv86Vqau J6QED7g+AvzqmLXqUU2RpYs3/H5yv1aJNH4yGNrr6vUvQOnoA3nRH5OF2hB+G+p8 JNWSu88IuMqk2h/+KJVGmSEZlBhfsjoW+yUGLncrdQ1nI4ir3IZxjDvXCdLNG31f Ic8drzEfra9ls4MTCAvFFOY3MCEH16IBqNXodv56FNmA70qmHlXoamyOp5Lwiftv e6jQsxZ078bxvcQKGAcB =bjhe -----END PGP SIGNATURE-----