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 5BEF513877A for ; Mon, 28 Jul 2014 14:42:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5B980E0C43; Mon, 28 Jul 2014 14:42:34 +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 6AD36E0BFC for ; Mon, 28 Jul 2014 14:42:33 +0000 (UTC) Received: from pomiot.lan (77-254-85-187.adsl.inetia.pl [77.254.85.187]) (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 6F3BE33FCB7; Mon, 28 Jul 2014 14:42:31 +0000 (UTC) Date: Mon, 28 Jul 2014 16:42:46 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Ian Stakenvicius Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined Message-ID: <20140728164246.21604cae@pomiot.lan> In-Reply-To: <53D65C3C.5030204@gentoo.org> References: <53D2A6C8.9060900@gentoo.org> <53D3BDE9.8000708@gentoo.org> <53D65C3C.5030204@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; 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: multipart/signed; micalg=pgp-sha512; boundary="Sig_/U1JsKcIj=MvyReYvJ5QYaB+"; protocol="application/pgp-signature" X-Archives-Salt: 63efc108-2413-4301-b66b-2d07aa15d37b X-Archives-Hash: 424cd05244d6818829f479383ddd426c --Sig_/U1JsKcIj=MvyReYvJ5QYaB+ Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-07-28, o godz. 10:20:44 Ian Stakenvicius napisa=B3(a): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 26/07/14 10:40 AM, Manuel R=FCger wrote: > > 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=20 > >> optionally explicitly-chosen through package.use (or USE=3D in=20 > >> 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 to). > >>=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=20 > >> 2013/06/27 20:42:55 aballier Exp $ > >>=20 > >> -EAPI=3D3 +EAPI=3D5 > >>=20 > >> DESCRIPTION=3D"Virtual for Kerberos V implementation" HOMEPAGE=3D""=20 > >> @@ -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""=20 > >> +IUSE=3D"heimdal mit-krb5" > >>=20 > >> DEPEND=3D"" -RDEPEND=3D"|| ( app-crypt/mit-krb5 app-crypt/heimdal )"=20 > >> +RDEPEND=3D"!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5=20 > >> app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 )=20 > >> + heimdal? ( app-crypt/heimdal )" + +REQUIRED_USE=3D"heimdal? > >> ( !mit-krb5 ) + mit-krb5? ( !heimdal )" > >>=20 > >>=20 > >> Thoughts? > >>=20 > >=20 > > Thinking in another direction: Would it be possible to introduce > > "pseudo-versioned" useflags? > >=20 > > This would solve a problem for virtual/libusb just with adding=20 > > IUSE=3D">=3Ddev-libs/libusb-1.0.18" > >=20 > > virtual/libusb-1-r1 depends on either dev-libs/libusb or=20 > > sys-freebsd/freebsd-lib. The latter one is only compatible with=20 > > libusb-1.0.9, so packages depending on >dev-libs/libusb-1.0.9 can't > > use the virtual. > >=20 > > Assuming freebsd-lib becomes compatible with dev-libs/libusb > > again, packages will have to switch back to the virtual to support > > both. > >=20 > > Depending on virtual/libusb[>=3Ddev-libs/libusb-1.0.18(+)] instead > > would just need a change in the virtual. >=20 > This sounds like something that should still be doable with two > versions of the virtual/libusb package... I mean, if something > *needs* a newer libusb than 1.0.9 , then it should appropriately > depend on a virtual/libusb that needs it. Otherwise, it shouldn't > matter which provider provides virtual/libusb-1 , right?? So we keep > virtual/libusb-1 as-is, and add a virtual/libusb-1.0.10 (or whatever > version is appropriate) for anything that needs a newer one. That > newer one would need to have a !sys-freebsd/freebsd-lib in it, I > think, to help keep it from being allowed to upgrade, but that itself > might not be necessary. Not a blocker but rather lack of this dependency. We'll probably have to mask it in bsd profiles as well but otherwise looks fine. --=20 Best regards, Micha=B3 G=F3rny --Sig_/U1JsKcIj=MvyReYvJ5QYaB+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT1mFnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO75QQANAMly0sTnMpB9nYmo1cum3F 6GGY49+87gbN+vcguf245DfM4rst/To+pZd0MXrVyQwZqqMG7HnAKO1u65qgPObO uux8RJjoi7GNxw2f82hrQTFS97wTvzm6FKCc/+vqz6X1QywQ5qSe5zl5NKVbrq9F bZIrB/B1YAbC5ay97rit9hlJ+NA5fvCwc/QdoFJhyPX1cQoRZbcjw5VwOhn1QVtZ PMhD4/Jusw66NLSU1FPe0qZz4FLf3QWV8BIxX3h2iUxSIzCGVSNo5cauE3yBP6yc tE3jgQLTsnPgd6ZZ7Js84H6hQTmzGq0OQMFdUfcxino6ykXkGSQVw5JmTrznLaT8 8IsiyU7/Di9K0c6q/S1Wtz+XSr5Pco69DNba37LGxGTsrl4fThCTs+XgSzfehVFr 6frFiy/foo/krC32inLg0CwYYDgdvMxlp3PI1mohIQ35hzgxdrZdFy3cMOZMAoWY hczOEWcwd2KdaZ3swswedmjYhyCVLEXO9JfgVG0aFrSnQXSXcKhNk8Jys3akAmdU EUZdORbH1TWqK8/dlGDq3fFNSSDNObb+32Il2OCCSnmeIeumMYhyPoSj49rZZh5I lKoAtgr+R5VwuFmPALluEYKQ3oCq9tIArRdpH5VcwPUxKfnAfNLe8XYnjfSOAesE BqD8g+DrAsjb4J2hZbYr =ydCS -----END PGP SIGNATURE----- --Sig_/U1JsKcIj=MvyReYvJ5QYaB+--