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