Dnia 2014-07-28, o godz. 10:20:44 Ian Stakenvicius <a...@gentoo.org> napisał(a):
> -----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. > > 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. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
