-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 28/07/14 10:42 AM, Michał Górny wrote: > 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. >
Just not including the sys-freebsd/freebsd-lib atom in the newer virtual generally makes sense, yes, but portage in particular will try to upgrade the virtual and therefore also switch the provider from freebsd-lib to the newer libusb on -uDN, right? A mask in profiles would do the trick (especially in this case due to there being two distinct sets of profiles for each provider) but it would be easier in the general case to handle this all in-ebuild if possible, wouldn't it? Back to my use flag suggestion -- this is an example that I don't think use flags could help; indeed i think the use flags would get in the way more than anything: #1, the newer version of the virtual would need to keep the flag for the missing provider to have any effect, and this just seems wrong; #2, the only flag-based blocking that could occur would be REQUIRED_USE or pkg_pretend, and both of those would keep an emerge -uDN @world from starting until resolved, instead of just disallowing the virtual from being upgraded. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPWaDQACgkQ2ugaI38ACPD3hQEArDTqKhKyys7lFDnKH6cyCLNu umPBhsTd1/vZQnijfgQA/3N9ry/LnTyeDyi0pSOqoEIODuYXCGQ7ksUslzQGTmzi =MKu7 -----END PGP SIGNATURE-----
