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

[Pacho Ramos]

El sáb, 26-07-2014 a las 08:05 +0000, Duncan escribió:
> Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted:
>
> > 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.
>
> What about handling each such virtual_USE as a USE_EXPAND?  VIRTUAL_* as
> reserved-namespace USE_EXPAND would give us full backward compatibility
> along with an immediately identifiable namespace and virtually (heh) no
> possibility of confusion with other configuration.
>
> Continuing with the earlier virtual/krb5 example, we'd have VIRTUAL_KRB5,
> with possible settings in make.conf of:
>
> VIRTUAL_KRB5=mit-krb5
> VIRTUAL_KRB5=heimdal
>
> Virtually no possibility of confusion with normal USE flags, and the
> matching virtual would be immediately identifiable, so no possibility of
> getting confused on what it applies to, either.
>

I would also prefer to use USE_EXPAND to not mix normal USEs with
virtuals... but I would go with using the same "VIRTUAL" variable for
all virtuals, otherwise people will end up having dozens of VIRTUAL_
statements in make.conf (one per virtual package)