Re: [gentoo-dev] Making a common sub-profile for no-multilib

["Anthony G. Basile" <blueness@gentoo.org>]

On 06/25/14 15:00, Chris Reffett wrote:
>
> On June 25, 2014 2:44:57 PM EDT, "Michał Górny" <mgorny@gentoo.org> wrote:
>> Dnia 2014-06-25, o godz. 13:01:48
>> Ian Stakenvicius <axs@gentoo.org> napisał(a):
>>
>>> At the moment there are two profiles in particular that do this,
>>> amd64/no-multilib and hardened/linux/uclibc/amd64 ..  It's possible
>> or
>>> likely there are others, too, on other arches perhaps.
>>>
>>> In general, it's good that repoman notices this because those
>> profiles
>>> don't support having the 32bit deps installed.  However, if one of
>>> those profiles ever moves from a dev profile to a stable one (and
>>> blueness mentioned he would like to make uclibc/amd64 stable), then
>>> those dependency.badindev warnings will suddenly turn into
>>> dependency.bad errors.
>>>
>>> The solution to this would seem to be to package.mask all of these
>>> 32-bit packages in the pure 64bit profiles.  However, having to do
>>> this in multiple locations is annoying.
>>>
>>> I would like to propose adding 'no-multilib/[arch]/package.mask'
>>> sub-profile(s), to allow all of these masks to go in one place.
>>>
>>> Populating package.mask should be fairly easy for amd64 at least,
>>> since anything depending on an app-emulation/emul-* will need to be
>>> masked.  However the merits of where the package.mask will go needs
>>> discussion.  Perhaps, for instance, it's time to adjust the profile
>>> tree hierarchy more aggressively instead of "piling on" with yet
>>> another subdir.
>> Forgive me for using such a words, but the profile tree is a well
>> stacked pile of crap. We have a dozen random profiles for each arch
>> then a dozen other profiles forked off them 'because the generic
>> arch profiles have crap' and a lot of profiles that inherit others
>> in a complex and semi-random manner.
>>
>> For example, abi_x86_64 and abi_x86_32 each need to be forced in 4
>> profiles. This proves that we have 4 distinct profiles for amd64 which
>> need to be kept in sync. If I change something, I need to perform
>> the change in 4 different profiles and make sure I didn't screw
>> something up.
>>
>> Then there's the x32 profile that inherits amd64 profile and therefore
>> requires reverting some of the stuff done on amd64. To do a complete
>> common change to x86-family multilib (like adding IUSE_IMPLICIT) I have
>> to modify 9 profiles.
>>
>> Now let's add to this circa 8 mips profiles, around 3 ppc profiles, 4
>> arm profiles and some more. Every arch organized in somewhat different
>> and totally non-documented manner.
>>
>> Long story short, doing anything to Gentoo profiles is utter pain
>> and comes with random breakage guarantee. Therefore, I'm asking -- nuke
>> those damn profiles, and start over! The current situation is
>> completely unmaintainable.
> +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.
>
> Chris
>
The profiles have caused us no end of suffering in hardened.  The 
hardened/linux/uclibc profiles are my attempt to avoid the "well stacked 
pile of crap" without creating more "crap", although that's debatable 
;)  The problem is the way stacking works.  You don't have control over 
the inheritance and so wind up turn things on, then reverting, then 
turning them on again on in the next layer etc.  We had luck 
disentangling selinux because it was orthogonal to the rest of hardened, 
but not so much luck when it came to the hardened/desktop subprofiles.

I've been trying to keep up with the multilib stuff for uclibc, so don't 
fret too much about those profiles, although any help is appreciated 
like repoman -d warnings.  I'd worry more about the rest of them.

However, in the long run, before we nuke them all and start over (and 
loose a lot of memory in the process) we may want to look into designs 
where we can control the inheritance better via portage. More syntax in 
the parent file may help here.

The issue has vexed me enough that I blogged about it: 
http://blogs.gentoo.org/blueness/2014/02/07/the-gentoo-profile-stacking-problem/

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA