[gentoo-dev] Binary package dependencies for sub-slot-less EAPIs

[W. Trevor King]

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