1 |
Dnia 2014-06-25, o godz. 13:01:48 |
2 |
Ian Stakenvicius <axs@g.o> napisał(a): |
3 |
|
4 |
> I would like to propose adding 'no-multilib/[arch]/package.mask' |
5 |
> sub-profile(s), to allow all of these masks to go in one place. |
6 |
> |
7 |
> Populating package.mask should be fairly easy for amd64 at least, |
8 |
> since anything depending on an app-emulation/emul-* will need to be |
9 |
> masked. However the merits of where the package.mask will go needs |
10 |
> discussion. Perhaps, for instance, it's time to adjust the profile |
11 |
> tree hierarchy more aggressively instead of "piling on" with yet |
12 |
> another subdir. |
13 |
> |
14 |
> Thoughts? |
15 |
|
16 |
I would go for a bit different way of handling arch profiles. This is |
17 |
an early idea that probably can't work but could make things a little |
18 |
bit easier to mangle. |
19 |
|
20 |
The arch/ tree starts with 'generic' subdirectories matching main |
21 |
arches -- like arm, mips, x86, sparc, powerpc, s390 (but not amd64). |
22 |
|
23 |
Each of arch trees contains an 'abis' subtree that contains mix-ins |
24 |
describing particular ABIs supported. For example, arch/x86/abis/x86, |
25 |
arch/x86/abis/amd64, arch/mips/abis/o32. |
26 |
|
27 |
Each of those mix-ins describes that basic stuff for ABI (like LIBDIR, |
28 |
standard CHOST), unmasks relevant ABI flags and p.masks them on |
29 |
packages that don't support a particular ABI. |
30 |
|
31 |
Now, each of those mix-ins may come with a sub-profile called 'default' |
32 |
that sets use.force & make.defaults for making the ABI the default ABI. |
33 |
I'm currently not sure if this will be really helpful since the small |
34 |
amount of work we may also put directly into 'real' profiles (described |
35 |
below). |
36 |
|
37 |
Moreover, each of those mix-ins may come with a 'no-multilib' |
38 |
sub-profile. This one -- aside from setting all the standard variables |
39 |
-- package.masks all the packages that were package.use.mask in parent |
40 |
profile. This way, we can keep all the masks almost in a single place. |
41 |
|
42 |
Then, we have multilib profiles like arch/x86/multilib/amd64, |
43 |
arch/x86/multilib/x32. Those inherit from all the relevant ABI profiles |
44 |
-- e.g. amd64 would inherit arch/x86/abis/x86 & |
45 |
arch/x86/abis/amd64[/default], and set the remaining variables for |
46 |
multilib. |
47 |
|
48 |
|
49 |
While I feel it's a bit complex, I think that's somehow a sane way to |
50 |
express what we have now without moving back and forth. Few extra key |
51 |
points: |
52 |
|
53 |
- minimal no of profiles in each 'parent' -- supposedly abis/ would |
54 |
have no parents, and possibly final profiles would have 'arch/base' |
55 |
as parent, |
56 |
|
57 |
- as already mentioned somewhere else, i'd rather see 'arch/base' |
58 |
instead of plain 'base' -- the idea is to put everything that's |
59 |
easier reverted than copied through all arch/ profiles, and have it |
60 |
inherited only by the final arch profiles. |
61 |
|
62 |
|
63 |
For example, the expanded inherits for arch/x86/multilib/amd64 would |
64 |
go like: |
65 |
|
66 |
1. arch/base -- that disables a lot of uncommon stuff, |
67 |
|
68 |
2. arch/x86/base [optionally] -- setting some generic defaults, |
69 |
|
70 |
3. arch/x86/abis/x86 -- setting support for 'x86' ABI, |
71 |
|
72 |
4. arch/x86/abis/x86/lib32 [optionally] -- overriding LIBDIR_x86 for |
73 |
compatibility with current SYMLINK_LIB screwup, |
74 |
|
75 |
5. arch/x86/abis/amd64 -- setting support for 'amd64' ABI, |
76 |
|
77 |
6. arch/x86/abis/amd64/default [optionally] -- setting 'amd64' |
78 |
as default ABI, |
79 |
|
80 |
7. arch/x86/multilib/amd64 -- finishing multilib setup. |
81 |
|
82 |
The key point here being that no profile is run twice. |
83 |
|
84 |
-- |
85 |
Best regards, |
86 |
Michał Górny |