Over on #gentoo-releng and in gentoo-catalyst@ we've been running into binary package dependency problems [1]. Before EAPI-5 and sub-slots, the version of dependency packages is not recorded in the binary package metadata (the Packages file). For example, a binary package for GCC built against mpc-0.8.2 will link to libmpc.so.2. If you install that package on a system that only has mpc-1.0.1 (and thus, libmpc.so.3), your cc1 will crash because libmpc.so.2 is missing. What we need is a way to track ABI sub-slot dependencies for all packages, even those that currently use EAPI-0.
My initial idea was to store a fake EAPI-5-style sub-slot information
in the binary package metadata, but further discussion on
#gentoo-portage pointed me at the toolchain folks:
10:33 < zmedico> dol-sen: wouldn't it be easier to just migrate
those pkgs to EAPI 5 + slot-operator?
10:34 * zmedico doesn't feel like doing extra work when EAPI 5
already does everything we need
…
11:16 < Tommy[D]_> Zero_Chaos: my suggestion: ask the toolchain guys
about their preferred way (like updating existing eclass,
using a new eclass, moving code into ebuilds) and when you
got that, do the needed work, including an EAPI-5 version of
toolchain ebuilds
I looked in bugzilla for requests to update the toolchain EAPIs, but
didn't find anything [2]. I don't want to bother people if the issue
had already been hashed out, and searching on Gmane turned up the
“[RFC] Drop EAPI=0 requirement for system packages.” thread from last
October [3]. This early comment from Rich seemed to summarize the
anti-EAPI-bump camp:
On Wed, Oct 17, 2012 at 03:00:12PM -0400, Rich Freeman wrote:
> A policy that says all new ebuilds shall use EAPI foo might result in
> fewer new ebuilds. Sure, they'll have new and shiny fooness, but
> arguably I'd rather have more packages supported on older EAPIs then
> fewer packages supported on newer ones.
>
> Again, as I stated before, things that actually benefit the end users
> like slot dependencies are fine to mandate when it makes sense to do
> so.
In other words, “Why force folks to do this if there is no benefit?”.
This is understandable, but I think the broken binary packages [1] are
enough of a visible benefit. The thread suggested filing bugs for
bumping effected packages, but for this issue “effected packages” is
“anything you might want to distribute as a binary package that uses
something without EAPI-5 sub-slots” [4]. I'm happy to start filing
bugs, but that doesn't strike me as the most productive way forward.
If anyone can think of other solutions besides tweaking Portage or
bumping a bunch of package EAPIs, I'd be happy to hear them ;).
Otherwise I'd be happy to hear suggestions about moving forward on at
least one of those fronts. Since I seem to be the most bothered by
this issue, it's only fair that I help with the itch scratching. I
just need a roadmap from the folks with commit access so I can start
chipping away at whichever solution y'all think looks most appealing
;).
Cheers,
Trevor
[1]: http://thread.gmane.org/gmane.linux.gentoo.catalyst/2137/focus=2237
[2]:
https://bugs.gentoo.org/buglist.cgi?short_desc=EAPI&resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&short_desc_type=allwordssubstr&component=Core%20system&component=Development&component=Core%20system&component=Development&product=Gentoo%20Linux
[3]: http://thread.gmane.org/gmane.linux.gentoo.devel/80705
[4]: Although on the catalyst side, only @system is really important.
--
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
