On 06/25/14 15:00, Chris Reffett wrote:
On June 25, 2014 2:44:57 PM EDT, "Michał Górny" <mgo...@gentoo.org> wrote:
Dnia 2014-06-25, o godz. 13:01:48
Ian Stakenvicius <a...@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 : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
