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 41A66198005 for ; Sun, 3 Mar 2013 11:41:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DD6C2E07B7; Sun, 3 Mar 2013 11:41:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DA67DE07AB for ; Sun, 3 Mar 2013 11:41:14 +0000 (UTC) Received: from portable (AMontpellier-651-1-453-97.w81-251.abo.wanadoo.fr [81.251.252.97]) (using SSLv3 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 6767E33DC68; Sun, 3 Mar 2013 11:41:12 +0000 (UTC) Date: Sun, 3 Mar 2013 12:41:07 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org, amd64@gentoo.org, tommy@gentoo.org Subject: Re: [gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported ABIs Message-ID: <20130303124107.50c7bf8e@portable> In-Reply-To: <20130303000230.13fea8b8@pomiocik.lan> References: <20130303000230.13fea8b8@pomiocik.lan> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-pc-linux-gnu) 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2d9d36d7-1072-427e-8d6c-a5f06f72d1ef X-Archives-Hash: 6b513af7d5128c1c99227235ccf42d4f On Sun, 3 Mar 2013 00:02:30 +0100 Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > With the introduction of support for x32 ABI it has become necessary > to enhance the multilib-build eclass with some kind of support for > specifying the supported/unsupported ABIs. >=20 > In this particular context, tetromino has noted that many packages > don't support the x32 ABI. From the ones currently using the eclass, > the one is app-emulation/wine. >=20 > I would like to enhance the eclass with the ability to specify > supported and unsupported ABIs. For that reason, I'd like to gather > your opinion on what would be the best solution. Preferably, I'd see > one that could work both for the eclass and multilib-portage so that > we wouldn't need to duplicate the same information. >=20 >=20 > 1) opt-in or opt-out? >=20 > So far, the multilib-capable packages did get support for all multilib > ABIs on given architecture enabled (assuming that the package is > keyworded for the arch). >=20 > As a next step from that, I think an opt-out solution be the simplest > and most consistent one. In this particular context: >=20 > MULTILIB_RESTRICT_ABIS=3D( ... ) >=20 > which would be an optional variable disabling support for problematic > ABIs in the packages which need it. >=20 >=20 > An alternative solution would be an opt-in like in python-r1: >=20 > MULTILIB_COMPAT=3D( ... ) >=20 > but so far, that would mean that all current packages will have to be > updated to list the currently supported ABIs. And it all sucks a bit > due to the gray zone between amd64/x86 keyword and ABIs. >=20 >=20 > And no, optional MULTILIB_COMPAT is a no-go. It's a weird breed of > opt-in and opt-out which is just awful. I'd go for opt-out (MULTILIB_RESTRICT_ABIS); Ideally we'd want all packages to support all abis, so what we should aim at is building for every abi. Also, opt-in has the big disadvantage that introducing a new abi requires a lot of tree-wide changes, which we tried to avoid since the beginning. > 2) USE flag names or ABI names? >=20 > Next thing to decide would be: whether the restrict should specify USE > flag names (like the eclass solution) or ABI names (like > portage-multilib and profiles). >=20 > The advantage of USE flags is that they are guaranteed to be unique > and clear. As in, two arches won't ever have the same USE flag for ABI > with the same name. >=20 > MULTILIB_RESTRICT_ABIS=3D( abi_x86_x32 ) >=20 > The advantage of ABI names is that multilib-portage is aware of them. > So, it's mostly about supporting a poor choice done without consulting > other developers. >=20 > MULTILIB_RESTRICT_ABIS=3D( x32 ) >=20 > The problem with that is that a new arch can define an ABI with > exactly the same name (since all ABI variables are profile-local). In > that case, the restriction will unexpectedly apply to that arch. >=20 >=20 > By the way, maybe we should move the flag -> ABI mapping from > the eclass to some global location in profiles? That would make it > possible to use the global flags from multilib-portage as well. >=20 > What are your thoughts? I'd prefer the useflag names for the sake of unicity, but I'm not sure I understand why and how multilib-portage needs it. What will multilib-portage uses it for ? If that's to gather and use its information to restrict some ABIs, then I assume you will have something like 'if multilib-portage then dont do anything multilib' in the eclass; well, you can very well export a variable translating the useflag names to abi names that multilib-portage can use too. I'm not sure you need the mapping on the profiles. A.