Automatic rebuilds with experimental EAPI 4-slot-abi

In response to recent discussion on the gentoo-dev mailing list, in portage-2.1.11.1 and 2.2.0_alpha112 I’ve added experimental support for EAPI “4-slot-abi”. This EAPI makes it possible for packages to be rebuilt automatically when necessary, so that you don’t have to do it manually (nor using a helper such as revdep-rebuild or perl-cleaner). Hopefully this feature will soon be coming to an official future EAPI. I’ll post some example usage scenarios from portage’s unit tests for EAPI “4-slot-abi”.

Here’s an example dev-libs/icu upgrade:

$ emerge -pu dev-libs/icu

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] dev-libs/icu-49 [4.8]
[ebuild R ] dev-libs/libxml2-2.7.8

As you can see, emerge detects that libxml has been built against an older version of dev-libs/icu, so it automatically rebuilds it against the newer version. Without EAPI support, typically a user handles this kind of rebuild manually, by running the revdep-rebuild helper to detect the breakage (or similarly running @preserved-rebuild with portage-2.2_alpha).

Here’s an example sys-libs/db upgrade:

$ emerge -pu sys-libs/db

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild NS ] sys-libs/db-4.8 [4.7]
[ebuild R ] app-office/libreoffice-3.5.4.2

In this case, emerge detects that libreoffice has been built against an older slot of sys-libs/db, so it automatically rebuilds it to link against the newer slot. This type of rebuild is not strictly necessary, unless you’d like emerge ‐‐depclean to be able to remove the older slot. If you want to avoid this kind of optional rebuild, you can use the emerge ‐‐rebuild-if-new-slot-abi=n option, or use ‐‐exclude=app-office/libreoffice if you want to be more specific (these options are documented in the emerge man page).

Here’s an example dev-libs/glib upgrade:

$ emerge -pu dev-libs/glib

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] dev-libs/glib-2.32.3 [2.30.2]
[ebuild R ] dev-libs/dbus-glib-0.98

In this case, emerge detects that dbus-glib has been built against an older version of dev-libs/glib, so it automatically rebuilds it against the newer version. Without EAPI support, typically a user handles this kind of rebuild manually, after being prompted by an ewarn message (revdep-rebuild does not handle this case, as noted in bug #297483).

If you are interested in experimenting with EAPI “4-slot-abi”, then please refer to the corresponding html documentation that is installed by >=sys-apps/portage-2.1.11 with USE=doc, and also to the emerge(1) man page for information about the related ‐‐ignore-built-slot-abi-deps and ‐‐rebuild-if-new-slot-abi options.

Update 2012-07-01
There’s now an overlay available for testing EAPI 4-slot-abi. Please refer to bug 424429 for details.

5 thoughts on “Automatic rebuilds with experimental EAPI 4-slot-abi”

  1. This is a cool feature.
    In future it could prevent me from updating icu (b/c that forces a rebuild of libreoffice – which tooks a looong time at my older notebook).

  2. Thanks a lot 🙂

    Only a question, remembering icu case, wouldn’t be possible for portage to automatically preserve old icu (or affected package) libs until all emerge is finalized to prevent icu based apps from being broken during update? Or that would have the same problems that are currently preventing preserve-libs feature to land stable?

    Thanks for the info

    1. wouldn’t be possible for portage to automatically preserve old icu (or affected package) libs until all emerge is finalized to prevent icu based apps from being broken during update

      Yes, and portage-2.2_alpha will do that when FEATURES=preserve-libs is enabled. So, EAPI 4-slot-abi and preserve-libs work well together in this way. What’s really nice about EAPI 4-slot-abi is that you don’t have to run @preserved-rebuild, because the need to rebuild is known in advance and it’s triggered automatically.

    2. Or that would have the same problems that are currently preventing preserve-libs feature to land stable?

      I think the automatic rebuilds made possible with EAPI 4-slot-abi could be considered as a prerequisite to having preserve-libs land in stable, because it’s ideal for the user to be able to know about rebuilds in advance and have them happen automatically. Also, being able to schedule the rebuilds in advance makes it possible to avoid the possibility of symbol collisions like those discussed here:

      http://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-new-portage-2-2-preserve-libs-behaviour

      1. From reading that blog post looks like, effectively, this would solve that issue as, per I see in flameeyes replies in that blog post, this enforces package rebuilds in advance preventing to have a mixture that could appear without eapi4-slot-abi is administrator forgets to manually run emerge @preserved-rebuild 🙂

Comments are closed.