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" <[email protected]> > > > > 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. Cheers, Trevor [1]: http://mid.gmane.org/[email protected] -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
