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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4498 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Pacho Ramos]

El dom, 11-05-2014 a las 20:56 +0200, Michał Górny escribió:
[...]
> 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,
[...]

Why is this needed? Thanks for the explanation :)

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/05/14 03:19 PM, Pacho Ramos wrote:
> El dom, 11-05-2014 a las 20:56 +0200, Michał Górny escribió: [...]
>> 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,
> [...]
> 
> Why is this needed? Thanks for the explanation :)
> 
> 

I believe that this relates to cases of, by example, a 32bit
pre-rolled binary package on amd64.  I expect one could use a specific
version range (upper/lower) for the dependency instead, so long as it
is just as accurate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlNycTQACgkQ2ugaI38ACPBswQEAugV6KeFBCPz30cBLeG7Ebsnn
Y0C8E4bG1WxSY5JNSfIA/2vEMZPdcbFMnfpHI0AEqvo7YkreXzvvo+oE6t0mlrI/
=W3gq
-----END PGP SIGNATURE-----

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

>>>>> On Sun, 11 May 2014, Michał Górny wrote:

> 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.

This looks like a problem similar to the one we had when porting from
monolithic to modular X11. There were some tools at the time that
would help with dependency checking:
http://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml

Maybe some of that old wisdom could be used for solving the new
problem?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Pacho Ramos]

El mar, 13-05-2014 a las 15:23 -0400, Ian Stakenvicius escribió:
> On 13/05/14 03:19 PM, Pacho Ramos wrote:
> > El dom, 11-05-2014 a las 20:56 +0200, Michał Górny escribió: [...]
> >> 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,
> > [...]
> > 
> > Why is this needed? Thanks for the explanation :)
> > 
> > 
> 
> I believe that this relates to cases of, by example, a 32bit
> pre-rolled binary package on amd64.  I expect one could use a specific
> version range (upper/lower) for the dependency instead, so long as it
> is just as accurate.

Ah, ok :)