[gentoo-dev] The gx86 multilib project -- masterplan

[gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

Hello,

Following the success of python-r1, the batch of patches I was sending
recently and some random testing, I'd like to introduce my ideas
and plans on how multilib could be introduced to gx86 in a simple
and sane manner.

My major goal with this mail is to summarize the ideas, the problems
and all the work that has been done already.


1. The USE flags and profiles
-----------------------------

The first step in introducing multilib would be to provide the USE
flags necessary to control building for respective ABIs in profiles.
The current proposed patches based on simple amd64 multilib are
available in [1].

From profiles PoV:

1. Each multilib-capable arch set provides USE_EXPAND with relevant
   multilib profiles.

     ABI_X86="32 x32 64"
     ABI_MIPS="o32 n32 n64"

2. All the USE_EXPAND variables are hidden in the base profile, and all
   the flags are masked.

3. Every arch relevant to the particular set of multilib flags unmasks
   and forces the flag for default ABI.

     x86 -> unmasks & forces abi_x86_32
     amd64 -> unmasks & forces abi_x86_64

4. Every multilib profile unmasks the flags for remaining supported
   ABIs and unhides the variable.

     amd64 multilib -> unmasks abi_x86_32, unhides ABI_X86

[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/83341


2. The USE flags and packages
-----------------------------

The packages requesting multilib support either inherit
the multilib-build [2] or its derivative (e.g. autotools-multilib),
or implement the necessary facilities by hand.

The following common rules apply (they are all handled by the eclass):

1. Each multilib-capable ebuilds adds multilib flags for all arches
   to IUSE (IUSE must be constant).

2. The relevant set of flags is enforced through profile flag masking,
   forcing and USE_EXPAND hiding. Therefore, the user only sees
   the flags which are really relevant.

   x86, amd64 no-multilib -> no flags (hidden)
   amd64 multilib -> ABI_X86="32 (64)" (latter forced)

3. The enabled set of ABIs is further filtered through MULTILIB_ABIS
   set by profile. Therefore, even with users mangling the masks they
   won't be able to build something irrelevant to the profile.

4. All the build and libdir details are handled by the multilib.eclass.
   Therefore, all ebuilds should be ready for it already.

5. If no relevant USE flags are selected (bug-case), fallback
   to default ABI is done.

[2]:http://thread.gmane.org/gmane.linux.gentoo.devel/83322


3. Inter-package dependencies
-----------------------------

The inter-package dependencies are done the best way possible --
explicitly ;). The package developers are supposed to know best which
of the dependencies need having same ABIs enabled and which don't.

1. The 'regular' multilib packages are supposed to use
   ${MULTILIB_USEDEP} from multilib-build.eclass on all dependencies
   which need multilib.

   RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
       dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"

   The dependencies will be required to have the same ABIs enabled
   as the package in question.

2. The specific cases can use the USE flags directly. For example,
   binary x86 packages can depend on abi_x86_32 unconditionally:

   RDEPEND="dev-libs/libfoo[abi_x86_32]"

   Due to proper profile USE flag forcing/masking, that dependency is
   valid both for amd64 multilib & real x86 system.


4. ABI-specific content
-----------------------

The gx86 multilib assumes that the majority of multilib packages will
install only 32-bit libraries and pkg-config files.

1. The installation of 32-bit data in libdir is done implicitly through
   multilib.eclass and econf awareness of ABI variable.

2. Any other content which needs to be ABI-aware (includes, *-config
   programs) need be handled by ebuilds explicitly.

3. Additionally, the autotools-multilib.eclass will ensure that headers
   installed to /usr/include are consistent between ABIs.


5. Solutions to specific problems
---------------------------------

1. x11-proto packages

Those packages install headers to /usr/include and pkg-config files
to /usr/lib64. This supposedly means that the headers could be
ABI-specific; however, so far I haven't seen a single difference.

Possible solutions:

a) check the headers by hand, move pkg-config files to /usr/share,

b) make the proto packages multilib. This will cause identical .pc
   files to be installed to lib32 & lib64 but will also enable eclass
   checks for header consistency.


2. packages which install ABI-dependent headers

e.g. libogg. The issue needs to be fixed in the specific ebuild.

a) fix the headers, e.g.:

  typedef short ogg_int16_t;
  typedef unsigned short ogg_uint16_t;
  typedef int ogg_int32_t;

to:

  #include <stdint.h>

  typedef int16_t ogg_int16_t;
  ...

b) install the header(s) in an alternate location. With packages using
   pkg-config, that would be easy.


3. packages which still reinvent pkg-config with their *-config

e.g. llvm. Really painful to solve; probably will require action both
on llvm ebuild side and consumer side.

a) long-term solution: convince upstream to use pkg-config.

b) short-term: rename the llvm-config script and use the renamed
   version for 32-bit build.


What are your thoughts?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Ciaran McCreesh]

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

On Sun, 27 Jan 2013 16:12:37 +0100
Michał Górny <mgorny@gentoo.org> wrote:
>    RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
>        dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"

This looks like it might be a bit fragile. Is it something better
addressed by an EAPI extension?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Pacho Ramos]

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

El dom, 27-01-2013 a las 16:12 +0100, Michał Górny escribió:
[...]
> 5. Solutions to specific problems
> ---------------------------------
> 
> 1. x11-proto packages
> 
> Those packages install headers to /usr/include and pkg-config files
> to /usr/lib64. This supposedly means that the headers could be
> ABI-specific; however, so far I haven't seen a single difference.
> 
> Possible solutions:
> 
> a) check the headers by hand, move pkg-config files to /usr/share,
> 
> b) make the proto packages multilib. This will cause identical .pc
>    files to be installed to lib32 & lib64 but will also enable eclass
>    checks for header consistency.
> 

Currently, emul packages can install /usr/lib32/pkgconfig files (when
enabling "development" USE flag). This was added because, as emul sets
tend to be obsolete in a few weeks, people compiling packages against
its lib32 provided libs were getting build failures due "native"
pkgconfig files (usually from newer libs) were being used.

Regarding /usr/include, it looks harder to solve, current emul packages
simply don't provide headers at all, but it caused issues like this in
the past:
https://bugs.gentoo.org/show_bug.cgi?id=299490

Maybe installing headers in other place would be interesting :/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Alexis Ballier]

On Sun, 27 Jan 2013 16:12:37 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> 5. Solutions to specific problems
> ---------------------------------
> 
> 1. x11-proto packages
> 
> Those packages install headers to /usr/include and pkg-config files
> to /usr/lib64. This supposedly means that the headers could be
> ABI-specific; however, so far I haven't seen a single difference.
> 
> Possible solutions:
> 
> a) check the headers by hand, move pkg-config files to /usr/share,
> 
> b) make the proto packages multilib. This will cause identical .pc
>    files to be installed to lib32 & lib64 but will also enable eclass
>    checks for header consistency.

b) sounds like what we should do by default while lobbying upstream to
do a) :)


> 2. packages which install ABI-dependent headers
> 
> e.g. libogg. The issue needs to be fixed in the specific ebuild.
> 
> a) fix the headers, e.g.:
> 
>   typedef short ogg_int16_t;
>   typedef unsigned short ogg_uint16_t;
>   typedef int ogg_int32_t;
> 
> to:
> 
>   #include <stdint.h>
> 
>   typedef int16_t ogg_int16_t;
>   ...
> 
> b) install the header(s) in an alternate location. With packages using
>    pkg-config, that would be easy.

b) is not an option: this will break those that do not use pkg-config
a) is the correct solution, in cooperation with upstream of course, and
it shouldn't be that hard for the libogg example since, as far as I can
see, they already have such typedefs for other OSes.


> 3. packages which still reinvent pkg-config with their *-config
> 
> e.g. llvm. Really painful to solve; probably will require action both
> on llvm ebuild side and consumer side.
> 
> a) long-term solution: convince upstream to use pkg-config.
> 
> b) short-term: rename the llvm-config script and use the renamed
>    version for 32-bit build.

yes, but b) is a mess as there will be no generic solution :(

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

On Sun, 27 Jan 2013 16:07:48 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 27 Jan 2013 16:12:37 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> >    RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> >        dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> 
> This looks like it might be a bit fragile. Is it something better
> addressed by an EAPI extension?

I have no idea. This one's clear and simple. Not sure how you could be
able to do that better in EAPI.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Sergei Trofimovich]

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

On Sun, 27 Jan 2013 17:30:22 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 27 Jan 2013 16:07:48 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Sun, 27 Jan 2013 16:12:37 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> > >    RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > >        dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > 
> > This looks like it might be a bit fragile. Is it something better
> > addressed by an EAPI extension?
> 
> I have no idea. This one's clear and simple. Not sure how you could be
> able to do that better in EAPI.

EAPI might allow lib[multiple?][use?][flags?] as an alias of [multiple?,use?,flags?].

-- 

  Sergei

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

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

On Sun, 27 Jan 2013 21:04:14 +0300
Sergei Trofimovich <slyfox@gentoo.org> wrote:

> On Sun, 27 Jan 2013 17:30:22 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sun, 27 Jan 2013 16:07:48 +0000
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > 
> > > On Sun, 27 Jan 2013 16:12:37 +0100
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > >    RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > > >        dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > > 
> > > This looks like it might be a bit fragile. Is it something better
> > > addressed by an EAPI extension?
> > 
> > I have no idea. This one's clear and simple. Not sure how you could be
> > able to do that better in EAPI.
> 
> EAPI might allow lib[multiple?][use?][flags?] as an alias of [multiple?,use?,flags?].

I still don't think that would be really helpful.

  dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]

is IMO just more confusing than the usual [ssl,...] -- people start
thinking 'does it mean something special?'

Unless you mean adding the brackets to the variable itself -- but that
will be just scary...

  dev-libs/libfoo${MULTILIB_USEDEP}

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Matt Turner]

On Sun, Jan 27, 2013 at 7:12 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 5. Solutions to specific problems
> ---------------------------------
>
> 1. x11-proto packages
>
> Those packages install headers to /usr/include and pkg-config files
> to /usr/lib64. This supposedly means that the headers could be
> ABI-specific; however, so far I haven't seen a single difference.
>
> Possible solutions:
>
> a) check the headers by hand, move pkg-config files to /usr/share,
>
> b) make the proto packages multilib. This will cause identical .pc
>    files to be installed to lib32 & lib64 but will also enable eclass
>    checks for header consistency.

See http://lists.x.org/archives/xorg-devel/2012-September/033715.html

In short, there seem to be a couple cases of platform-dependent
substitutions in headers, but for the most part they're platform
independent.

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

On Sun, 27 Jan 2013 11:14:27 -0800
Matt Turner <mattst88@gentoo.org> wrote:

> On Sun, Jan 27, 2013 at 7:12 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > 5. Solutions to specific problems
> > ---------------------------------
> >
> > 1. x11-proto packages
> >
> > Those packages install headers to /usr/include and pkg-config files
> > to /usr/lib64. This supposedly means that the headers could be
> > ABI-specific; however, so far I haven't seen a single difference.
> >
> > Possible solutions:
> >
> > a) check the headers by hand, move pkg-config files to /usr/share,
> >
> > b) make the proto packages multilib. This will cause identical .pc
> >    files to be installed to lib32 & lib64 but will also enable eclass
> >    checks for header consistency.
> 
> See http://lists.x.org/archives/xorg-devel/2012-September/033715.html
> 
> In short, there seem to be a couple cases of platform-dependent
> substitutions in headers, but for the most part they're platform
> independent.

Yes, I have seen the substitutions but so far, it seems that they give
the same values for both amd64 ABIs. I'm not sure if other platforms
have the same characteristics.

I'd prefer just using b) now and getting back to this whenever
the header check starts to fail for some platform. Then we would have
to move the headers.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Maciej Mrozowski]

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

On Sunday 27 of January 2013 19:11:16 Micha³ Górny wrote:
> On Sun, 27 Jan 2013 21:04:14 +0300
> 
> Sergei Trofimovich <slyfox@gentoo.org> wrote:
> > On Sun, 27 Jan 2013 17:30:22 +0100
> > 
> > Micha³ Górny <mgorny@gentoo.org> wrote:
> > > On Sun, 27 Jan 2013 16:07:48 +0000
> > > 
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > On Sun, 27 Jan 2013 16:12:37 +0100
> > > > 
> > > > Micha³ Górny <mgorny@gentoo.org> wrote:
> > > > >    RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > > > >    
> > > > >        dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > > > 
> > > > This looks like it might be a bit fragile. Is it something better
> > > > addressed by an EAPI extension?
> > > 
> > > I have no idea. This one's clear and simple. Not sure how you could be
> > > able to do that better in EAPI.
> > 
> > EAPI might allow lib[multiple?][use?][flags?] as an alias of
> > [multiple?,use?,flags?].
> I still don't think that would be really helpful.
> 
>   dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]
> 
> is IMO just more confusing than the usual [ssl,...] -- people start
> thinking 'does it mean something special?'
> 
> Unless you mean adding the brackets to the variable itself -- but that
> will be just scary...
> 
>   dev-libs/libfoo${MULTILIB_USEDEP}

Alternatively, less fragile but more verbose would be eclass function to 
produce dependency string. While it may sound as overkill - we already do it 
in KDE:

'add_kdebase_dep':

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-
functions.eclass?view=markup

Example usage:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-
base/pykde4/pykde4-4.9.5.ebuild?view=markup


-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michael Weber]

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

Hi,

What's the primary Idea behind multilib at all?
Isn't it just a workaround to keep prebuild software
from lazy/incapable/dead upstreams working (skype, ...)?

Is there any other real use besides bragging about processor
capabilities and compiling an stage1 boot loader?

Please don't get me wrong. I honor the whole effort done to bring this
magic into portage/..., but I see limits in the underlying file system.

The current solution suggested by FHS-2.3 [1] is to use
/lib<qual> and /usr/lib<qual>, which works for runtime emul- packages,
since software either installed to /opt/{${PN},bin} or had no
alternative in /bin or /usr/bin.

On 01/27/2013 02:40 PM, Thomas Sachau wrote:> 2. How do you handle
other abi-specific files like headers or binaries
> and cases like binaries with abi-specific content? Is it possible
> to preserve them for all requested abis or to preserve them for an 
> non-default abi?

On 01/27/2013 05:08 PM, Pacho Ramos wrote:> Maybe installing headers
in other place would be interesting :/

This is getting wired now, when we get an x86, x86_64 and x86_32
(srsly?) implementation of cp(1).

Either we avoid collision python style with /bin/${PN}-<qual> and some
link magic, to select the "best" <qual> according to moon phases.

In the spirit of FHS, I thought about introducing /bin<qual> for some
time, but this continues with other dirs.
We would need /var/lib<qual> as well (/var/lib/munin/ has ABI specific
.rrd files),
/usr/include<qual>/ ... wait a minute.

What about separating these ABIs on top dir and keeping the respective
sub-trees clean, like /<qual>/{,usr/}{bin,lib}?

/<qual>/ could be realised by one of these systems
- - chroot (just like /<any-other-distro> chroots), needs root.
- - Gentoo/PREFIX style
- - modified runtime linker to pic correct LD_LIBRARY_PATH.

These /<qual>/ can be anything, like different ABIs,
different libc implementations, different keyword (stable, testing),
different Distros, - as long as it runs with the current kernel.
Well, thin-provisioning, qemu, *random virtualization*.

One ABI, maybe the one that can run/chroot all others sould be defined
as qual="", just like non-multilib systems.

Replication of /<qual>/{home,usr/portage} can be avoided by symlinks
or bind-mounts, or hardlinks.
(Srsly, /usr/portage/"ebuilds,profiles,metadata,caches" has to be in
/var/portage.)

It'd be a pretty good solution for restraining mentioned (malicious)
software, /skype/ for example.

Some roundups have to be made for exhausive $PATH, X11 .desktop files,
to enable starting other /<qual>/

Comments?

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEI20AACgkQknrdDGLu8JAGBAD+MPkmNxKSCrHcAnj5PUaxyTM1
Hhymj3cHaxBuTFHlK78A/2t5qJNyg1c0nc6FSePKXq+MXWp/RVDWMb5XCpfEh4dR
=xmPN
-----END PGP SIGNATURE-----

Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michael Weber]

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

On 01/30/2013 09:35 AM, Michael Weber wrote:
> These /<qual>/ can be anything, like different ABIs, different libc
> implementations, different keyword (stable, testing), different
> Distros, - as long as it runs with the current kernel. Well,
> thin-provisioning, qemu, *random virtualization*.

Did I ever mention, you can boot into these /<qual>/!?!

initrd context:
  "mount root partition $ROOTDEV at $TARGET"
  mkdir /fun
  mount -o bind $TARGET/<qual> /fun
  exec switch_root /fun /sbin/init

Mount output get's confusing about multiple lines
mentioning $ROOTDEV, esp. for init.d/fsck, but
IMHO fsck should be done in initrd, and not single-user mode
with read-only mount and with binaries from that broken partition.
- - other story.

Or have it on separate partition - like the traditional "I switch
distros" aproach.

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEI3zEACgkQknrdDGLu8JBrLgEAgI2m92etcKYF7/5wWEmJc1DZ
3apcjuDokN3WxUcxDdIA/A67DJBV5OKmVxX9wSaeomakg8Ql5oCqETXM6b9n1uy+
=Lkq3
-----END PGP SIGNATURE-----

Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

On Wed, 30 Jan 2013 01:39:16 +0100
Maciej Mrozowski <reavertm@gmail.com> wrote:

> On Sunday 27 of January 2013 19:11:16 Micha³ Górny wrote:
> > On Sun, 27 Jan 2013 21:04:14 +0300
> > 
> > Sergei Trofimovich <slyfox@gentoo.org> wrote:
> > > On Sun, 27 Jan 2013 17:30:22 +0100
> > > 
> > > Micha³ Górny <mgorny@gentoo.org> wrote:
> > > > On Sun, 27 Jan 2013 16:07:48 +0000
> > > > 
> > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > > On Sun, 27 Jan 2013 16:12:37 +0100
> > > > > 
> > > > > Micha³ Górny <mgorny@gentoo.org> wrote:
> > > > > >    RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > > > > >    
> > > > > >        dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > > > > 
> > > > > This looks like it might be a bit fragile. Is it something better
> > > > > addressed by an EAPI extension?
> > > > 
> > > > I have no idea. This one's clear and simple. Not sure how you could be
> > > > able to do that better in EAPI.
> > > 
> > > EAPI might allow lib[multiple?][use?][flags?] as an alias of
> > > [multiple?,use?,flags?].
> > I still don't think that would be really helpful.
> > 
> >   dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]
> > 
> > is IMO just more confusing than the usual [ssl,...] -- people start
> > thinking 'does it mean something special?'
> > 
> > Unless you mean adding the brackets to the variable itself -- but that
> > will be just scary...
> > 
> >   dev-libs/libfoo${MULTILIB_USEDEP}
> 
> Alternatively, less fragile but more verbose would be eclass function to 
> produce dependency string. While it may sound as overkill - we already do it 
> in KDE:

And in ruby, and in arfrever's python....

add_foo_dep $(add_bar_dep ...) ... oh wait, it doesn't work like that.

-- 
Best regards,
Michał Górny

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

Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

On Wed, 30 Jan 2013 09:35:12 +0100
Michael Weber <xmw@gentoo.org> wrote:

> What's the primary Idea behind multilib at all?
> Isn't it just a workaround to keep prebuild software
> from lazy/incapable/dead upstreams working (skype, ...)?

Yes. And 32-bit wine for 32-bit Windows apps which are common.

> On 01/27/2013 02:40 PM, Thomas Sachau wrote:> 2. How do you handle
> other abi-specific files like headers or binaries
> > and cases like binaries with abi-specific content? Is it possible
> > to preserve them for all requested abis or to preserve them for an 
> > non-default abi?
> 
> On 01/27/2013 05:08 PM, Pacho Ramos wrote:> Maybe installing headers
> in other place would be interesting :/
> 
> This is getting wired now, when we get an x86, x86_64 and x86_32
> (srsly?) implementation of cp(1).
> 
> Either we avoid collision python style with /bin/${PN}-<qual> and some
> link magic, to select the "best" <qual> according to moon phases.

We don't want 32-bit cp. Thomas likes to support every weird idea
coming from a random user, I don't.

> In the spirit of FHS, I thought about introducing /bin<qual> for some
> time, but this continues with other dirs.
> We would need /var/lib<qual> as well (/var/lib/munin/ has ABI specific
> .rrd files),
> /usr/include<qual>/ ... wait a minute.
> 
> What about separating these ABIs on top dir and keeping the respective
> sub-trees clean, like /<qual>/{,usr/}{bin,lib}?
> 
> /<qual>/ could be realised by one of these systems
> - - chroot (just like /<any-other-distro> chroots), needs root.
> - - Gentoo/PREFIX style
> - - modified runtime linker to pic correct LD_LIBRARY_PATH.
> 
> These /<qual>/ can be anything, like different ABIs,
> different libc implementations, different keyword (stable, testing),
> different Distros, - as long as it runs with the current kernel.
> Well, thin-provisioning, qemu, *random virtualization*.

No. 32-bit chroot is an old idea and has nothing to do with multilib.
It's an alternative to multilib and there's no point in reinventing it.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iJwEAQEIAAYFAlEI7rsACgkQfXuS5UK5QB02KAP7BLGGggDrHYeO4gC+nW3sKUEr
LI9Gr/D8ag8eGXpAtYphlZgQYQ1uXWk50MHOiPyO6x6blKV+wUtaH3oyc62POU2W
w3hsadhzVW6YRekzbUAKqdyhLqjgcliyWfoQQ6GGkRXAgKq4FcdTet972xd4omPQ
vyiTx+1LJ/yUyKIIArI=
=0uAW
-----END PGP SIGNATURE-----

Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michael Weber]

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

On 01/30/2013 10:58 AM, Michał Górny wrote:
> On Wed, 30 Jan 2013 09:35:12 +0100 Michael Weber <xmw@gentoo.org>
> wrote:

> We don't want 32-bit cp. Thomas likes to support every weird idea 
> coming from a random user, I don't.
What is wrong with "random" or "user"? Should I take "random user"
personally? Honestly, I have no idea.

Where do you want to draw the line?
How would you handle library packages shipping binaries?
Just `rm "${D}"/usr/bin`?

>> In the spirit of FHS, I thought about introducing /bin<qual> for
>> some time, but this continues with other dirs.
> 
>> What about separating these ABIs on top dir and keeping the
>> respective sub-trees clean, like /<qual>/{,usr/}{bin,lib}?
> No. 32-bit chroot is an old idea and has nothing to do with
> multilib.

Right, that was the intent of my mail.
Not to question some multilib internal stupidity like how to handle
clashing pkg-config files but to question the approach in common.
Maybe FatELF would work with this multilib/USE approch w/o cluttering
the file system [1].

  Multilib: funny clashes all over the tree, partial blessed by FHS.

  Emul- packages, frozen, incapable of compiling and adding additional
  stuff - collision avoidance by upstream.

  Separated trees/chroots/... to be merged in $PATH et. al.

Is there any consent on how to proceed?

I support an slim solution, but as it turns out "architecture
independent" from FHS is just a lie. Or handled very badly.

[1] http://en.wikipedia.org/wiki/Fat_binary

> It's an alternative to multilib and there's no point in reinventing
> it.
Yeah, did not reinvent it, just want to re-think it's validity.

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlEJBGsACgkQknrdDGLu8JDMWAD+Ksp5FmqOKgHxuLtR/smWJCgU
SjnM/V64GFnGrCtSqdoA/32BHJdFrO/6YzUZTMhHp+o9u/QgAEjgbKRutdptqZwQ
=dSTv
-----END PGP SIGNATURE-----

Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan

[Michał Górny]

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

On Wed, 30 Jan 2013 12:30:51 +0100
Michael Weber <xmw@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 01/30/2013 10:58 AM, Michał Górny wrote:
> > On Wed, 30 Jan 2013 09:35:12 +0100 Michael Weber <xmw@gentoo.org>
> > wrote:
> 
> > We don't want 32-bit cp. Thomas likes to support every weird idea 
> > coming from a random user, I don't.
> What is wrong with "random" or "user"? Should I take "random user"
> personally? Honestly, I have no idea.

Sorry, I didn't meant to offend anyone. I'm just saying that if nobody
shows a real need for having a 32-bit 'cp', then there's no point
in having that. How would you benefit from having it?

> Where do you want to draw the line?
> How would you handle library packages shipping binaries?
> Just `rm "${D}"/usr/bin`?

64-bit executables overwrite 32-bit ones. Correct order and the problem
solves itself.

> >> In the spirit of FHS, I thought about introducing /bin<qual> for
> >> some time, but this continues with other dirs.
> > 
> >> What about separating these ABIs on top dir and keeping the
> >> respective sub-trees clean, like /<qual>/{,usr/}{bin,lib}?
> > No. 32-bit chroot is an old idea and has nothing to do with
> > multilib.
> 
> Right, that was the intent of my mail.
> Not to question some multilib internal stupidity like how to handle
> clashing pkg-config files but to question the approach in common.

I don't understand the problem with pkg-config files. pkg-config lies
in lib32/lib64, so the files are separate and don't clash.

>   Multilib: funny clashes all over the tree, partial blessed by FHS.

Clashes are mostly people's faults. I keep my headers tidy; sadly, many
people believe that constant API is not an important thing and you end
up really bad.

- -- 
Best regards,
Michał Górny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iJwEAQEIAAYFAlEJCB0ACgkQfXuS5UK5QB2VMwP/bjCt2BI8hn6QGN4ff03vBx1P
hmyUzw4DKKbNI5S5XYz6VprVTjh3YAm8oq8gZs3NuySNe81oyHdjn9xWO8mPOvk5
z0MxbQvrvem+HxSNEqmNtO5jxMUgMx+se6ysazn8TTd6UXXAT73mPHNoMDByznWX
3nnrELQUG4dKFxPYXDE=
=vMqF
-----END PGP SIGNATURE-----