Dnia 2014-06-25, o godz. 13:01:48 Ian Stakenvicius <a...@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
signature.asc
Description: PGP signature
