From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A263013877A for ; Wed, 25 Jun 2014 19:14:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45750E0B95; Wed, 25 Jun 2014 19:13:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 54EB5E0B90 for ; Wed, 25 Jun 2014 19:13:34 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 6BF9334001A for ; Wed, 25 Jun 2014 19:13:32 +0000 (UTC) Message-ID: <53AB1F84.6050807@gentoo.org> Date: Wed, 25 Jun 2014 15:14:12 -0400 From: "Anthony G. Basile" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Making a common sub-profile for no-multilib References: <53AB007C.5070306@gentoo.org> <20140625204457.6d6ed82b@pomiot.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 9bc97fb0-1ed3-4c96-b6dd-e5394889c498 X-Archives-Hash: 86394e04c9851e50b2189f124cd472db On 06/25/14 15:00, Chris Reffett wrote: > > On June 25, 2014 2:44:57 PM EDT, "Michał Górny" wrote: >> Dnia 2014-06-25, o godz. 13:01:48 >> Ian Stakenvicius 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