public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: Ian Stakenvicius <axs@gentoo.org>
Cc: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Making a common sub-profile for no-multilib
Date: Wed, 25 Jun 2014 20:44:57 +0200	[thread overview]
Message-ID: <20140625204457.6d6ed82b@pomiot.lan> (raw)
In-Reply-To: <53AB007C.5070306@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

  reply	other threads:[~2014-06-25 18:47 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 [this message]
2014-06-25 19:00   ` Chris Reffett
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=20140625204457.6d6ed82b@pomiot.lan \
    --to=mgorny@gentoo.org \
    --cc=axs@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