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 DE33913877A for ; Mon, 28 Jul 2014 14:21:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5CA73E0D71; Mon, 28 Jul 2014 14:20:54 +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 6A9F2E09F0 for ; Mon, 28 Jul 2014 14:20:53 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 39E8433FD9B for ; Mon, 28 Jul 2014 14:20:52 +0000 (UTC) Message-ID: <53D65C3C.5030204@gentoo.org> Date: Mon, 28 Jul 2014 10:20:44 -0400 From: Ian Stakenvicius 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> <53D3BDE9.8000708@gentoo.org> In-Reply-To: <53D3BDE9.8000708@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Archives-Salt: 6a120d7c-be60-4130-b202-cc77fd4def34 X-Archives-Hash: 6e8c880df1d384b48c0202f6fd4905af -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/07/14 10:40 AM, Manuel Rüger 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? >> >> The idea here is that the package satisfying a virtual could be >> optionally explicitly-chosen through package.use (or USE= 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. >> >> 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). >> >> I don't know if this would aid heavy binpkg users or not. >> >> >> For completion, here's one of those rather messy examples: >> >> --- 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 $ >> >> -EAPI=3 +EAPI=5 >> >> DESCRIPTION="Virtual for Kerberos V implementation" HOMEPAGE="" >> @@ -11,7 +11,12 @@ LICENSE="" SLOT="0" KEYWORDS="alpha amd64 arm >> hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~amd64-fbsd >> ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos" -IUSE="" >> +IUSE="heimdal mit-krb5" >> >> DEPEND="" -RDEPEND="|| ( app-crypt/mit-krb5 app-crypt/heimdal )" >> +RDEPEND="!mit-krb5? ( !heimdal? ( || ( app-crypt/mit-krb5 >> app-crypt/heimdal ) ) ) + mit-krb5? ( app-crypt/mit-krb5 ) >> + heimdal? ( app-crypt/heimdal )" + +REQUIRED_USE="heimdal? >> ( !mit-krb5 ) + mit-krb5? ( !heimdal )" >> >> >> Thoughts? >> > > 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=">=dev-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[>=dev-libs/libusb-1.0.18(+)] instead > would just need a change in the virtual. > > Cheers, > > Manuel > 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. Or is it more complicated than that and i'm missing something? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPWXDwACgkQ2ugaI38ACPBrOAD9EXzlINqnSFQ/SvSTcvVyiMLr ZkMzt4ud98dvItB++5oBAKIg5Nc0p4jjtAj/DN1YsBw8yWkRyCLylJ6G7iKeeKT3 =U9cS -----END PGP SIGNATURE-----