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 E13B513877A for ; Sat, 26 Jul 2014 14:41:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73650E0DCC; Sat, 26 Jul 2014 14:40:56 +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 6AEB5E0D9D for ; Sat, 26 Jul 2014 14:40:55 +0000 (UTC) Received: from [192.168.0.12] (p5797163F.dip0.t-ipconnect.de [87.151.22.63]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mrueg) by smtp.gentoo.org (Postfix) with ESMTPSA id 480EB340092 for ; Sat, 26 Jul 2014 14:40:54 +0000 (UTC) Message-ID: <53D3BDE9.8000708@gentoo.org> Date: Sat, 26 Jul 2014 16:40:41 +0200 From: =?ISO-8859-1?Q?Manuel_R=FCger?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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] RFC: USE flags in virtuals, to allow a specific provider to be determined References: <53D2A6C8.9060900@gentoo.org> In-Reply-To: <53D2A6C8.9060900@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oew1aKIf5FvcEo9Fsi6Q1LfkPVWC78orh" X-Archives-Salt: 6d1b9b9a-b18d-4f43-896b-89a47747690a X-Archives-Hash: 969ecfec1144ccc4fcd954063f1f4eff This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oew1aKIf5FvcEo9Fsi6Q1LfkPVWC78orh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/25/2014 08:49 PM, Ian Stakenvicius wrote: > Hey all.. So, putting aside for now how much of a mess this would be > to implement in the virtuals' ebuilds themselves, what do people think > of changing the virtuals so that they contain an entry in IUSE for > each provider that can satisfy it? >=20 > The idea here is that the package satisfying a virtual could be > optionally explicitly-chosen through package.use (or USE=3D in > make.conf, perhaps) instead of having an entry in @world, that way if > nothing depends on the virtual then it and the provider can be > --depclean'ed from the system. The idea is specifically NOT to have > rdeps depend on these flags, that would undermine the whole purpose of > the virtual; it would just be for end-users to set if they so chose. >=20 > This may also help with getting portage to peg a virtual's provider to > a specific package instead of constantly trying to switch from one to > another, ie, how systemd kept getting pulled in, in relation to the > upower virtual. Note - I haven't done any tests to determine if this > actually helps with such issues tho (or even attempted to reproduce > them, as i was apparently one of the lucky ones that it didn't happen t= o). >=20 > I don't know if this would aid heavy binpkg users or not. >=20 >=20 > For completion, here's one of those rather messy examples: >=20 > --- virtual/krb5-0.ebuild 2013-06-28 09:04:47.000000000 -0400 > +++ virtual/krb5-0.ebuild.new 2014-07-25 14:47:48.000000000 -0400 > @@ -2,7 +2,7 @@ > # Distributed under the terms of the GNU General Public License v2 > # $Header: /var/cvsroot/gentoo-x86/virtual/krb5/krb5-0.ebuild,v 1.2 > 2013/06/27 20:42:55 aballier Exp $ >=20 > -EAPI=3D3 > +EAPI=3D5 >=20 > DESCRIPTION=3D"Virtual for Kerberos V implementation" > HOMEPAGE=3D"" > @@ -11,7 +11,12 @@ > LICENSE=3D"" > SLOT=3D"0" > KEYWORDS=3D"alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh > sparc x86 ~amd64-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos" > -IUSE=3D"" > +IUSE=3D"heimdal mit-krb5" >=20 > DEPEND=3D"" > -RDEPEND=3D"|| ( app-crypt/mit-krb5 app-crypt/heimdal )" > +RDEPEND=3D"!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 > app-crypt/heimdal ) ) ) > + mit-krb5? ( app-crypt/mit-krb5 ) > + heimdal? ( app-crypt/heimdal )" > + > +REQUIRED_USE=3D"heimdal? ( !mit-krb5 ) > + mit-krb5? ( !heimdal )" >=20 >=20 > Thoughts? >=20 Thinking in another direction: Would it be possible to introduce "pseudo-versioned" useflags? This would solve a problem for virtual/libusb just with adding IUSE=3D">=3Ddev-libs/libusb-1.0.18" virtual/libusb-1-r1 depends on either dev-libs/libusb or sys-freebsd/freebsd-lib. The latter one is only compatible with libusb-1.0.9, so packages depending on >dev-libs/libusb-1.0.9 can't use the virtual. Assuming freebsd-lib becomes compatible with dev-libs/libusb again, packages will have to switch back to the virtual to support both. Depending on virtual/libusb[>=3Ddev-libs/libusb-1.0.18(+)] instead would just need a change in the virtual. Cheers, Manuel --oew1aKIf5FvcEo9Fsi6Q1LfkPVWC78orh 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJT073uXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc8ecQAJU1re4VJdvGN0kT14R3WGEX mnwBWvQ8plaEu9lCnqlNEqMfQIYt4l0jCZrdtYL6j8l79x/HhDFV86odJdVADnYk lKP5KLwlcG9tAQz9fRVAboNOZVXjhERp5j76tUudk/uEAzSB2F/Vc1RhzCfrA7il k7yZv1Y6e6qFGMezkQvGMiOdWeAuHN9GAO1I4hCKUEyGwqNxaD9Ep5Vq5KHx/K1X jE/zcu/nQbSVyotFHeAk0AWwkkzp4HW/aaJkFLsUjyZ3UZ0fTZ2FfXIQE4Zp0igm iy87b+FnCtVOnVCv1qyn1m3+GbEYmYqWMccMAOf8ALEj98J1hJpSHZsOt72Ht+ut 5NFNry9eZGKBOxW3hkWhr0xkQMil1J0oISJ6fR/DQ/bRU5oGhjAkc/sxBizhKY6r R/TtNE83tRoyBRzIG5EjNIMeMPt5SgLAi1Cw3rWMswjAyfvgXxE5RE2HGRsFTfmM bsFFYT3Ruqhk1dikgPzpgwvfnvWRvTApPsNftdEtC/O66l3JO5VIR5OPabaDLr8r byo4GwPhUzCXpNapGwqipBzubr6UMshnfctE6Bctbt/TnrlTHwQa8+mlI24f6TK4 0w7MhecCmi0c9zbwi5shHUkKk0pEkv/t8C2rg25+gLVnVQkqZi8orM4CfnkW3WF/ ll3Cy3TQVxYVFrvwMso5 =V4Mf -----END PGP SIGNATURE----- --oew1aKIf5FvcEo9Fsi6Q1LfkPVWC78orh--