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 1A5821392EF for ; Wed, 25 Jun 2014 19:01:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 394EFE081E; Wed, 25 Jun 2014 19:00:33 +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 5B4DCE080E for ; Wed, 25 Jun 2014 19:00:27 +0000 (UTC) Received: from [172.24.1.192] (unknown [65.216.151.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: creffett) by smtp.gentoo.org (Postfix) with ESMTPSA id 24DB633F702 for ; Wed, 25 Jun 2014 19:00:22 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: <20140625204457.6d6ed82b@pomiot.lan> References: <53AB007C.5070306@gentoo.org> <20140625204457.6d6ed82b@pomiot.lan> 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 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [gentoo-dev] Making a common sub-profile for no-multilib From: Chris Reffett Date: Wed, 25 Jun 2014 15:00:24 -0400 To: gentoo-dev@lists.gentoo.org Message-ID: X-Archives-Salt: e664a16c-225a-4a5d-a3c3-f908e8dbf60c X-Archives-Hash: 704d82eeba9aa79d5fe277ba661d27b1 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