Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined

[Michał Górny]

Dnia 2014-07-28, o godz. 10:20:44
Ian Stakenvicius <axs@g.o> 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