| 1 |
On 06/25/14 15:00, Chris Reffett wrote: |
| 2 |
> |
| 3 |
> On June 25, 2014 2:44:57 PM EDT, "Michał Górny" <mgorny@g.o> wrote: |
| 4 |
>> Dnia 2014-06-25, o godz. 13:01:48 |
| 5 |
>> Ian Stakenvicius <axs@g.o> napisał(a): |
| 6 |
>> |
| 7 |
>>> At the moment there are two profiles in particular that do this, |
| 8 |
>>> amd64/no-multilib and hardened/linux/uclibc/amd64 .. It's possible |
| 9 |
>> or |
| 10 |
>>> likely there are others, too, on other arches perhaps. |
| 11 |
>>> |
| 12 |
>>> In general, it's good that repoman notices this because those |
| 13 |
>> profiles |
| 14 |
>>> don't support having the 32bit deps installed. However, if one of |
| 15 |
>>> those profiles ever moves from a dev profile to a stable one (and |
| 16 |
>>> blueness mentioned he would like to make uclibc/amd64 stable), then |
| 17 |
>>> those dependency.badindev warnings will suddenly turn into |
| 18 |
>>> dependency.bad errors. |
| 19 |
>>> |
| 20 |
>>> The solution to this would seem to be to package.mask all of these |
| 21 |
>>> 32-bit packages in the pure 64bit profiles. However, having to do |
| 22 |
>>> this in multiple locations is annoying. |
| 23 |
>>> |
| 24 |
>>> I would like to propose adding 'no-multilib/[arch]/package.mask' |
| 25 |
>>> sub-profile(s), to allow all of these masks to go in one place. |
| 26 |
>>> |
| 27 |
>>> Populating package.mask should be fairly easy for amd64 at least, |
| 28 |
>>> since anything depending on an app-emulation/emul-* will need to be |
| 29 |
>>> masked. However the merits of where the package.mask will go needs |
| 30 |
>>> discussion. Perhaps, for instance, it's time to adjust the profile |
| 31 |
>>> tree hierarchy more aggressively instead of "piling on" with yet |
| 32 |
>>> another subdir. |
| 33 |
>> Forgive me for using such a words, but the profile tree is a well |
| 34 |
>> stacked pile of crap. We have a dozen random profiles for each arch |
| 35 |
>> then a dozen other profiles forked off them 'because the generic |
| 36 |
>> arch profiles have crap' and a lot of profiles that inherit others |
| 37 |
>> in a complex and semi-random manner. |
| 38 |
>> |
| 39 |
>> For example, abi_x86_64 and abi_x86_32 each need to be forced in 4 |
| 40 |
>> profiles. This proves that we have 4 distinct profiles for amd64 which |
| 41 |
>> need to be kept in sync. If I change something, I need to perform |
| 42 |
>> the change in 4 different profiles and make sure I didn't screw |
| 43 |
>> something up. |
| 44 |
>> |
| 45 |
>> Then there's the x32 profile that inherits amd64 profile and therefore |
| 46 |
>> requires reverting some of the stuff done on amd64. To do a complete |
| 47 |
>> common change to x86-family multilib (like adding IUSE_IMPLICIT) I have |
| 48 |
>> to modify 9 profiles. |
| 49 |
>> |
| 50 |
>> Now let's add to this circa 8 mips profiles, around 3 ppc profiles, 4 |
| 51 |
>> arm profiles and some more. Every arch organized in somewhat different |
| 52 |
>> and totally non-documented manner. |
| 53 |
>> |
| 54 |
>> Long story short, doing anything to Gentoo profiles is utter pain |
| 55 |
>> and comes with random breakage guarantee. Therefore, I'm asking -- nuke |
| 56 |
>> those damn profiles, and start over! The current situation is |
| 57 |
>> completely unmaintainable. |
| 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 |
| 61 |
> |
| 62 |
The profiles have caused us no end of suffering in hardened. The |
| 63 |
hardened/linux/uclibc profiles are my attempt to avoid the "well stacked |
| 64 |
pile of crap" without creating more "crap", although that's debatable |
| 65 |
;) The problem is the way stacking works. You don't have control over |
| 66 |
the inheritance and so wind up turn things on, then reverting, then |
| 67 |
turning them on again on in the next layer etc. We had luck |
| 68 |
disentangling selinux because it was orthogonal to the rest of hardened, |
| 69 |
but not so much luck when it came to the hardened/desktop subprofiles. |
| 70 |
|
| 71 |
I've been trying to keep up with the multilib stuff for uclibc, so don't |
| 72 |
fret too much about those profiles, although any help is appreciated |
| 73 |
like repoman -d warnings. I'd worry more about the rest of them. |
| 74 |
|
| 75 |
However, in the long run, before we nuke them all and start over (and |
| 76 |
loose a lot of memory in the process) we may want to look into designs |
| 77 |
where we can control the inheritance better via portage. More syntax in |
| 78 |
the parent file may help here. |
| 79 |
|
| 80 |
The issue has vexed me enough that I blogged about it: |
| 81 |
http://blogs.gentoo.org/blueness/2014/02/07/the-gentoo-profile-stacking-problem/ |
| 82 |
|
| 83 |
-- |
| 84 |
Anthony G. Basile, Ph.D. |
| 85 |
Gentoo Linux Developer [Hardened] |
| 86 |
E-Mail : blueness@g.o |
| 87 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 88 |
GnuPG ID : F52D4BBA |
Archives