1 |
Dnia 2014-06-25, o godz. 13:01:48 |
2 |
Ian Stakenvicius <axs@g.o> napisał(a): |
3 |
|
4 |
> At the moment there are two profiles in particular that do this, |
5 |
> amd64/no-multilib and hardened/linux/uclibc/amd64 .. It's possible or |
6 |
> likely there are others, too, on other arches perhaps. |
7 |
> |
8 |
> In general, it's good that repoman notices this because those profiles |
9 |
> don't support having the 32bit deps installed. However, if one of |
10 |
> those profiles ever moves from a dev profile to a stable one (and |
11 |
> blueness mentioned he would like to make uclibc/amd64 stable), then |
12 |
> those dependency.badindev warnings will suddenly turn into |
13 |
> dependency.bad errors. |
14 |
> |
15 |
> The solution to this would seem to be to package.mask all of these |
16 |
> 32-bit packages in the pure 64bit profiles. However, having to do |
17 |
> this in multiple locations is annoying. |
18 |
> |
19 |
> I would like to propose adding 'no-multilib/[arch]/package.mask' |
20 |
> sub-profile(s), to allow all of these masks to go in one place. |
21 |
> |
22 |
> Populating package.mask should be fairly easy for amd64 at least, |
23 |
> since anything depending on an app-emulation/emul-* will need to be |
24 |
> masked. However the merits of where the package.mask will go needs |
25 |
> discussion. Perhaps, for instance, it's time to adjust the profile |
26 |
> tree hierarchy more aggressively instead of "piling on" with yet |
27 |
> another subdir. |
28 |
|
29 |
Forgive me for using such a words, but the profile tree is a well |
30 |
stacked pile of crap. We have a dozen random profiles for each arch |
31 |
then a dozen other profiles forked off them 'because the generic |
32 |
arch profiles have crap' and a lot of profiles that inherit others |
33 |
in a complex and semi-random manner. |
34 |
|
35 |
For example, abi_x86_64 and abi_x86_32 each need to be forced in 4 |
36 |
profiles. This proves that we have 4 distinct profiles for amd64 which |
37 |
need to be kept in sync. If I change something, I need to perform |
38 |
the change in 4 different profiles and make sure I didn't screw |
39 |
something up. |
40 |
|
41 |
Then there's the x32 profile that inherits amd64 profile and therefore |
42 |
requires reverting some of the stuff done on amd64. To do a complete |
43 |
common change to x86-family multilib (like adding IUSE_IMPLICIT) I have |
44 |
to modify 9 profiles. |
45 |
|
46 |
Now let's add to this circa 8 mips profiles, around 3 ppc profiles, 4 |
47 |
arm profiles and some more. Every arch organized in somewhat different |
48 |
and totally non-documented manner. |
49 |
|
50 |
Long story short, doing anything to Gentoo profiles is utter pain |
51 |
and comes with random breakage guarantee. Therefore, I'm asking -- nuke |
52 |
those damn profiles, and start over! The current situation is |
53 |
completely unmaintainable. |
54 |
|
55 |
-- |
56 |
Best regards, |
57 |
Michał Górny |