From: Chris Reffett <creffett@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Making a common sub-profile for no-multilib
Date: Wed, 25 Jun 2014 15:00:24 -0400 [thread overview]
Message-ID: <b68d472e-db02-49a8-a655-0fc082b59252@email.android.com> (raw)
In-Reply-To: <20140625204457.6d6ed82b@pomiot.lan>
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
next prev parent reply other threads:[~2014-06-25 19:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-25 17:01 [gentoo-dev] Making a common sub-profile for no-multilib Ian Stakenvicius
2014-06-25 18:44 ` Michał Górny
2014-06-25 19:00 ` Chris Reffett [this message]
2014-06-25 19:14 ` Anthony G. Basile
2014-06-25 19:11 ` Rich Freeman
2014-06-25 20:01 ` Andreas K. Huettel
2014-07-02 13:30 ` Rich Freeman
2014-07-02 18:14 ` [gentoo-dev] " Duncan
2014-07-02 23:06 ` Jonathan Callen
2014-07-03 4:59 ` Duncan
2014-07-03 7:05 ` Jonathan Callen
2014-07-03 9:05 ` Duncan
2014-07-03 9:43 ` Michał Górny
2014-07-03 10:58 ` [gentoo-dev] " Michał Górny
2014-07-03 12:07 ` Peter Stuge
2014-07-03 12:12 ` Michał Górny
2014-07-03 12:42 ` Peter Stuge
2014-07-03 12:33 ` Rich Freeman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b68d472e-db02-49a8-a655-0fc082b59252@email.android.com \
--to=creffett@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox