From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-65514-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 487AE1387FD
for <garchives@archives.gentoo.org>; Tue, 1 Apr 2014 15:32:39 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id F12FEE0AA7;
Tue, 1 Apr 2014 15:32:29 +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 01931E09B5
for <gentoo-dev@lists.gentoo.org>; Tue, 1 Apr 2014 15:32:28 +0000 (UTC)
Received: from pomiot.lan (77-254-69-105.adsl.inetia.pl [77.254.69.105])
(using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: mgorny)
by smtp.gentoo.org (Postfix) with ESMTPSA id E707733FBE4;
Tue, 1 Apr 2014 15:32:26 +0000 (UTC)
Date: Tue, 1 Apr 2014 17:32:08 +0200
From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: axs@gentoo.org
Subject: Re: [gentoo-dev] Stable masks on multilib packages
Message-ID: <20140401173208.2e5f55f7@pomiot.lan>
In-Reply-To: <533AD74B.3080508@gentoo.org>
References: <20140401001617.42fdc3bc@pomiot.lan>
<533AD74B.3080508@gentoo.org>
Organization: Gentoo
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
boundary="Sig_/XiZ53hsim3Fz00_osCdgOjv"; protocol="application/pgp-signature"
X-Archives-Salt: 6586f235-7bde-4425-a3cd-286d881597f6
X-Archives-Hash: 71650717e5d6481fca96fa505057835e
--Sig_/XiZ53hsim3Fz00_osCdgOjv
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Dnia 2014-04-01, o godz. 11:12:11
Ian Stakenvicius <axs@gentoo.org> napisa=B3(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>=20
> On 31/03/14 06:16 PM, Micha=B3 G=F3rny wrote:
> > Hello, all.
> >=20
> > The late multilib ppc issues made me re-check our stable masks on=20
> > abi_x86_* flags and, honestly, I'm not sure if we're doing things=20
> > the right way. First, a quick summary.
> >=20
> >=20
> > Let's consider dev-libs/elfutils that has a dependency on
> > app-arch/bzip2. If we're building 32-bit elfutils, it needs 32-bit=20
> > libbz2. This is enforced through a dep in form of:
> >=20
> > app-arch/bzip2[${MULTILIB_USEDEP}]
> >=20
> > that gets expanded into:
> >=20
> > app-arch/bzip2[abi_x86_32(-)?,abi_x86_64(-)?,...,abi_mips_o32(-)?,...]
> >
> > which means that any of the ABI_* flags that gets enabled on
> > elfutils, needs to be enabled on bzip2 as well. Of course, some of
> > use.forcing and masking gets applied here but that doesn't really
> > matter.
> >=20
> >=20
> > Now, since we're pretty much converting a lot of different
> > packages, some of them are eligible for stabilization earlier than
> > the others. However, the extra MULTILIB_USEDEPs enforce stabilizing
> > multilib dependencies before the actual packages which made a few
> > developers unhappy.
> >=20
> > That's why we decided to stable-mask the flags on affected
> > packages. Since the flags are masked on stable, people can
> > stabilize packages independently of whether their converted deps
> > are stable or not. We will be worrying about that consistency once
> > we decide to unmask the flags.
> >=20
> > The extra advantage of that is that we can avoid pushing stable
> > users into the mess involved with partial conversion of emul-linux.
> > The idea is pretty simple: we keep emul-linux for stable, and once
> > everything is ready, we stable-unmask the flags and let stable
> > users grok multilib.
> >=20
> >=20
> > Now, to the problem. Currently we're just stable-masking
> > abi_x86_32 on amd64. This serves the latter purpose well and seems
> > to work for the former. This is probably because the remaining flag
> > is use.forced (abi_x86_64 on amd64, and abi_x86_32 on x86) which
> > seems to add it to implicit IUSE somehow.
> >=20
> > floppym has done some research w/ stable elfutils and no stable=20
> > converted bzip2. It seems that if abi_x86_32 is stable.use.masked=20
> > and abi_x86_64 is use.forced, repoman groks it. However, if we
> > remove abi_x86_64 from use.force, it properly reports flag mismatch
> > error (since no stable bzip2 has IUSE=3Dabi_x86_64).
> >=20
> > Now, I honestly have no idea if this implicit use.force behavior
> > is PMS-y or not, and how other PMs handle it. I can't find
> > something like this in the PMS but that doc is horribly hard to
> > cross-reference, so I might be missing something. I'd appreciate if
> > someone could help me with that.
> >=20
> >=20
> > That said, I have an alternate idea inspired by the ppc breakage.
> > I'm thinking of replacing the amd64 abi_x86_32 mask with a global
> > stable mask of all abi_*_* flags on the relevant packages.
> >=20
> > Differences:
> >=20
> > 1) old solution: native flag is forced, other flags are masked. new
> > solution: all flags are masked.
> >=20
> > 2) old solution: we need to replicate the masks properly for
> > different arches/profiles. new solution: we can keep a single mask
> > for all arches.
> >=20
> > 3) old solution: MULTILIB_USEDEP magically works (w/ portage at
> > least). new solution: since all flags are disabled,
> > MULTILIB_USEDEP is a no-op and old packages match correctly.
> >=20
> > 4) old solution: forced native flag runs the native build. new
> > solution: fallback code runs the native build (since no flags are
> > enabled).
> >=20
> >=20
> > Your thoughts?
> >=20
>=20
>=20
> ... how messy is this going to be on current systems, if implemented?
> This -is- going to cause use flag changes on a whackload of packages,
> which at minimum I expect means a bunch of needless rebuilds.
>=20
> I think it's probably best to keep with the current path, and just
> hurry up the migration on x86. If we switch to masking all abi_*_*'s,
> then not only do we rebuild a whackload of packages now, but we also
> end up rebuilding them again when we remove the abi_*_* mask, -even
> if- the alternative abi's aren't needed.
Note that the same issue is spilling into ppc now that vapier wants to
introduce multilib there. If we keep going the current way, we need to
mask abi_ppc_32 in the ppc profiles, and that means yet another copy of
the same mask to maintain in sync.
> A note on #3: if MULTILIB_USEDEP -isnt- working on other PMs, i hope
> we have bug reports and we should work to resolve those ASAP or
> abandon the project/find a different solution. We're over a year into
> it though (i think?) so i expect it's fine since I don't remember
> hearing of any issues yet...
I don't know how many people are using Gentoo with alternative PMs
and stable keywords. I think Paludis could be a case but then, I don't
know how Exherbo incorporates our multilib into their package system.
> on a side note, to follow up -- when we do remove the masks, what're
> the thoughts on perhaps changing the multilib profile on amd64 to
> auto-enable abi_x86_32 flags on some packages? Indeed, if the
> toolchain is converted to multilib-build, would this be enough to
> differentiate between amd64-multilib and pure64? (bootstrapping may
> of course still be a problem if users are trying to switch, but
> probably not any more of a problem than it is right now, right?)
Could you be more specific on which packages? I used to think about
enabling it globally but now I see that autounmask would do a pretty
good work of unmasking the flags whenever necessary.
--=20
Best regards,
Micha=B3 G=F3rny
--Sig_/XiZ53hsim3Fz00_osCdgOjv
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQJ8BAEBCgBmBQJTOtv+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC
MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO8lAQALLNAt+RcaUS4Un6OCzPFyhk
fYTBAgrVUHiJ3vI5cATQMJyZ8eIbbnkoEY46sB9+LGbxVBEk9fbd+31EZIY8/Jw2
4bKlMuOpE9LWccNrLneMvlmALZa5L+T8htlGx0awMsvHN/6arV77ItKKtRCJdef2
HpIyZ4BBcK8H5THCJ1P5wJ2fhFZHU4gpENFAPMrncyqkY7+Rn9r/DpFi1DDCxqdx
/SlWqnb48JoA8Io92OA63jWqxx98dFfBqE6fIdq+p5RyAknpyabFs30zI6e6UAd/
kM7LXcmwV+OGorR0SbGa8wJWOwusNgVUR/XsFrkeDV4nE1edHPsChkBH6w+I2LIy
QyU50QTOK2NKkcIMe+8nUNnhK7XybtFHoZrU6xMfLfKxHwwpasSiAPOWLOXORMv3
2mA51LdaUohJc82L2hyuTG6OlI9LdQrfwLPQioAGDXDF0GKPn+r8PIK7oxfZC767
/tBNaN+9urLk6KUM3ANkeD5/+0UzqrYJbMzCp1Bs3DLlC6ocQeq0otNHTg9MMc+Z
cTublUuntcaMlFjUEwE8i/lB51RBmwE/CC1aKQlWegIBmjT1rAkdvZ1mGSW/jR3L
im8oCOYrn7/UGID48gr7Vpnyoaq3oPB5ETqAW3FnsvAU0cCJzOvX0k4OoUVPK0WE
p86sAdeqpsMaTwGfhAda
=glV7
-----END PGP SIGNATURE-----
--Sig_/XiZ53hsim3Fz00_osCdgOjv--