Gentoo Archives: gentoo-dev

From: Chris Reffett <creffett@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Making a common sub-profile for no-multilib
Date: Wed, 25 Jun 2014 19:01:01
Message-Id: b68d472e-db02-49a8-a655-0fc082b59252@email.android.com
In Reply to: Re: [gentoo-dev] Making a common sub-profile for no-multilib by "Michał Górny"
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

Replies

Subject Author
Re: [gentoo-dev] Making a common sub-profile for no-multilib "Anthony G. Basile" <blueness@g.o>