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 E73C51385AE for ; Sun, 20 Jan 2013 23:53:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C44FE21C046; Sun, 20 Jan 2013 23:52:57 +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 B2BDAE062C for ; Sun, 20 Jan 2013 23:52:56 +0000 (UTC) Received: from [192.168.178.20] (p548D2CC0.dip.t-dialin.net [84.141.44.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tommy) by smtp.gentoo.org (Postfix) with ESMTPSA id 3D44B33DA3E for ; Sun, 20 Jan 2013 23:52:55 +0000 (UTC) Message-ID: <50FC834D.2070004@gentoo.org> Date: Mon, 21 Jan 2013 00:52:45 +0100 From: Thomas Sachau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib References: <20130120201131.5afcbf48@pomiocik.lan> <50FC7731.2090708@gentoo.org> <1358723418.30392.5.camel@kanae> In-Reply-To: <1358723418.30392.5.camel@kanae> X-Enigmail-Version: 1.4.6 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF0B6D2F286E5D1DC6150C771" X-Archives-Salt: 16ab5333-8381-4546-b335-3ce10efa7461 X-Archives-Hash: a1faeec7c5159031e574097fa25796a9 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0B6D2F286E5D1DC6150C771 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gilles Dartiguelongue schrieb: > Le lundi 21 janvier 2013 =C3=A0 00:01 +0100, Thomas Sachau a =C3=A9crit= : >> Micha=C5=82 G=C3=B3rny schrieb: >>> Hello, >>> >>> There is a fair interest in multilib and while still early, it would = be >>> a good moment to decide on how USE flags to use for it. >>> >>> The current attempts are mostly using USE=3Dmultilib which is not rea= lly >>> expressive and poor. What I would go for is a clear variable specifyi= ng >>> which targets package is built for. >>> >>> >>> This raises the following questions: >>> >>> 1) do we want the default ABI to be switchable? >>> >>> 2) do we want irrelevant ABIs to be visible to emerge users? >>> >>> By 2) I mean: do we want the users to see stuff like: >>> >>> MULTILIB_ABIS=3D"amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) >>> (-ppc64_abi2) (-ppc64_abi3) ..." >>> >>> or just the relevant part. >>> >>> To be honest, I don't know if there's other way to hide USE flags tha= n >>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split >>> the flags per-arch, i.e. have: >>> >>> MULTILIB_AMD64=3D"abi1 abi2 abi3" >>> MULTILIB_PPC64=3D"abi1 abi2 abi3" >>> >>> with appropriate USE_EXPAND_HIDDEN set by profiles. >>> >>> >>> What are your thoughts? Which arches would like to use multilib? What= >>> names for ABIs do you suggest? >>> >> >> So you want to re-implement multilib-portage in an eclass without the >> additional benefits a package-manager level implementation has? >=20 > Well that's the point of the eclass that was proposed a few days ago > allow building multiple ABIs. Having clear USE-dep like python-r1.eclas= s > is imho the way to go. >=20 > As said in another reply of this thread, USE=3Dmultilib really is a > solution that has its problems (no fine PM control for ABIs, slow > updates of emul-pkgs) to the current problem and portage-multilib, well= > it's a subject that pops up from time to time I have no idea how and > will it will come nor do I have time to help on that front. multilib-portage exists and works for years, the problem usually is, that posts about it are ignored until i write something about "planned to ask council", which results in new requests to be fulfilled (for the inclusion of this feature in the next EAPI). This could also get us rid of USE=3Dmultilib and the emul packages. ;-) > However this eclass would enable quick and easy per-ebuild support for > multiple ABIs just like python-r1 and friends, and this is a good thing= > for every maintainer that wants to provide this kind of support. I know= > I would, at least to get rid of the always lagging emul packages. As already written in another thread not long ago, the USE flag part (shown USE flags per arch and USE flag dependencies) will be pretty hard to implement at eclass level. So i will wait and see, if someone can surprise me with a solution, that works as good as multilib-portage without bad side effects or additional work for all sides. --=20 Thomas Sachau Gentoo Linux Developer --------------enigF0B6D2F286E5D1DC6150C771 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iJwEAQECAAYFAlD8g1MACgkQG7kqcTWJkGcW6QP+MFwK7iqyLAMifXRFYccjhaK8 1w7d1tpnEIq6oKvD+1IdhXR8wsDsJzpVv1dKgFqANTFHJayXWzRJJKkOhNxkpd7d uHmHg8qRxvX3NTgX494jntXGF+J2Il8rzd6cJYyYqvRYFgKHxVqv9NqeDdzvtBjD TIC3kvlsfFmfP0cNazY= =Tuoz -----END PGP SIGNATURE----- --------------enigF0B6D2F286E5D1DC6150C771--