[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Making a common sub-profile for no-multilib
From:       Chris Reffett <creffett () gentoo ! org>
Date:       2014-06-25 19:00:24
Message-ID: b68d472e-db02-49a8-a655-0fc082b59252 () email ! android ! com
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]