Re: [gentoo-dev] Making a common sub-profile for no-multilib

["Michał Górny" <mgorny@gentoo.org>]

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

Dnia 2014-06-25, o godz. 13:01:48
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> I would like to propose adding 'no-multilib/[arch]/package.mask'
> sub-profile(s), to allow all of these masks to go in one place.
> 
> Populating package.mask should be fairly easy for amd64 at least,
> since anything depending on an app-emulation/emul-* will need to be
> masked.  However the merits of where the package.mask will go needs
> discussion.  Perhaps, for instance, it's time to adjust the profile
> tree hierarchy more aggressively instead of "piling on" with yet
> another subdir.
> 
> Thoughts?

I would go for a bit different way of handling arch profiles. This is
an early idea that probably can't work but could make things a little
bit easier to mangle.

The arch/ tree starts with 'generic' subdirectories matching main
arches -- like arm, mips, x86, sparc, powerpc, s390 (but not amd64).

Each of arch trees contains an 'abis' subtree that contains mix-ins
describing particular ABIs supported. For example, arch/x86/abis/x86,
arch/x86/abis/amd64, arch/mips/abis/o32.

Each of those mix-ins describes that basic stuff for ABI (like LIBDIR,
standard CHOST), unmasks relevant ABI flags and p.masks them on
packages that don't support a particular ABI.

Now, each of those mix-ins may come with a sub-profile called 'default'
that sets use.force & make.defaults for making the ABI the default ABI.
I'm currently not sure if this will be really helpful since the small
amount of work we may also put directly into 'real' profiles (described
below).

Moreover, each of those mix-ins may come with a 'no-multilib'
sub-profile. This one -- aside from setting all the standard variables
-- package.masks all the packages that were package.use.mask in parent
profile. This way, we can keep all the masks almost in a single place.

Then, we have multilib profiles like arch/x86/multilib/amd64,
arch/x86/multilib/x32. Those inherit from all the relevant ABI profiles
-- e.g. amd64 would inherit arch/x86/abis/x86 &
arch/x86/abis/amd64[/default], and set the remaining variables for
multilib.


While I feel it's a bit complex, I think that's somehow a sane way to
express what we have now without moving back and forth. Few extra key
points:

- minimal no of profiles in each 'parent' -- supposedly abis/ would
  have no parents, and possibly final profiles would have 'arch/base'
  as parent,

- as already mentioned somewhere else, i'd rather see 'arch/base'
  instead of plain 'base' -- the idea is to put everything that's
  easier reverted than copied through all arch/ profiles, and have it
  inherited only by the final arch profiles.


For example, the expanded inherits for arch/x86/multilib/amd64 would
go like:

1. arch/base -- that disables a lot of uncommon stuff,

2. arch/x86/base [optionally] -- setting some generic defaults,

3. arch/x86/abis/x86 -- setting support for 'x86' ABI,

4. arch/x86/abis/x86/lib32 [optionally] -- overriding LIBDIR_x86 for
compatibility with current SYMLINK_LIB screwup,

5. arch/x86/abis/amd64 -- setting support for 'amd64' ABI,

6. arch/x86/abis/amd64/default [optionally] -- setting 'amd64'
as default ABI,

7. arch/x86/multilib/amd64 -- finishing multilib setup.

The key point here being that no profile is run twice.

-- 
Best regards,
Michał Górny

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