[gentoo-dev] The gx86-multilib project needs your help! (+ roadmap reminder)

[Michał Górny]

Hello, developers and users.

The gx86-multilib project is working hard to bring our users a better
experience in multilib support. Eventually, we would like to phase out
emul-linux and replace it with less flawed multilib-build solution.
However, that requires a lot of work and we need your help.

One of the major flaws of the emul-linux solution was that a single
package corresponded to multiple libraries. For proper multilib
support, we need to unbundle those and replace the dependencies on
emul-linux with detailed library dependencies. Doing this properly
often requires access to the executables.

The issue is that many involved packages are proprietary and fetch-
-restricted. The multilib team is unable to reach the executables for
most of this software, and that's why we would really appreciate help
from developers and users that have got the relevant packages installed.


Before I get into the fine details, I'd like to explain a bit
the roadmap for multilib support in Gentoo. It comprises of three
stages:


stage I -- gx86-multilib in testing, emul-linux in stable
---------------------------------------------------------

Until all packages are updated properly, we prefer our stable users
using emul-linux. While gx86-multilib is slowly getting in shape,
issues can still occur -- most importantly, remaining pre-built
emul-linux libraries can depend on different SONAMEs of multilib
libraries.

In this stage, we'd like to focus on:

1. converting end-user packages to depend on
  || ( emul-linux-x86-* ( multilib-packages... ) ),

2. converting end-user package dependencies to multilib.

The abi_x86_32 support code in emul-linux is mostly meant for testing
convenience and we don't really want new packages to depend on that.


stage II -- gx86-multilib and emul-linux in stable
--------------------------------------------------

Once we fix all the dependencies and stabilize the revbumps, we can
focus on moving gx86-multilib to stable. This involves three steps:

1. removing IUSE=abi_x86_32 hacks from emul-linux -- those should no
longer be necessary, and will make switching more painful,

2. removing package.use.stable.mask on abi_x86_32,

3. releasing a news item about the new flags.


stage III -- emul-linux phased out
----------------------------------

Once we are sure that everything works fine, we start package.masking
emul-linux for removal.


We need the most help with updating pre-built package dependencies.
Since with many proprietary software we can't access the actual
executables to read their dependencies, we'd really appreciate
developers helping us by either updating the package dependencies
themselves, submitting patches to us or at least submitting 'readelf -d'
results for all installed executables.

A proper dependency string (during stages I and II above)
for a pre-built software looks like:

  RDEPEND="
    || (
      (
        emul-linux-x86-baselibs[-abi_x86_32(-)]
        emul-linux-x86-xlibs[-abi_x86_32(-)]
      )
      (
        >=sys-apps/util-linux-2.24.1-r3:0[abi_x86_32(-)]
        dev-libs/libgcrypt:0/20[abi_x86_32(-)]
        x11-libs/libX11:0/0[abi_x86_32(-)]
      )
    )
  "

Few things worth noticing:

1. the use of '|| ()' allows us to support both emul-linux and multilib
packages during migration period,

2. [-abi_x86_32(-)] on emul-linux is not strictly necessary but will
help portage 'switch' to multilib deps once multilib is enabled
on the system rather than keeping emul-linux compat metapackages,

3. USE dependencies against EAPI<5 ebuilds are a mess, so it's
recommended to depend on version of ebuild that is at least EAPI=5,
e.g. via >= dependency or new enough subslot,

4. whenever possible, depend on the specific subslot that is known to
provide SONAME equal to the required by your package, e.g. for
libgcrypt.so.20 you depend on libgcrypt:0/20,

5. please remember to revbump your package after updating
the dependencies. Dynamic dependencies in portage are fragile
and sometimes do not work. Reinstalling a binary package shouldn't be
a major pain to users, and will guarantee proper dependencies in vardb.


We really appreciate all the help we can get, and we'd like to thank
all the developers and users that are helping us already. In case of
any questions, please do not hesitate to reply to this mail or contact
us directly.

--
Best regards,
Michał Górny