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

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPSpsgACgkQ2ugaI38ACPCBGwD6A7Dlras5l/L9Fc1SA8K8oR3K
LQKY5g/vbdvYFKtooDoBAKdLiFySl24mHKA0O2YScxmr4g5tvusVAd3dxWTIjnat
=gSFT
-----END PGP SIGNATURE-----

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

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

I guess that would solve some of the issues we've had with virtuals in
the past. I support the idea, however, I'm not sure of the technical
consequences it might have.

I would leave the REQUIRED_USE out. It's a hassle to write, and if an
user decides to set multiple use flags on such a virtual, why not just
let him do it?


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/07/14 03:04 PM, Luis Ressel wrote:
> I guess that would solve some of the issues we've had with virtuals
> in the past. I support the idea, however, I'm not sure of the
> technical consequences it might have.
> 
> I would leave the REQUIRED_USE out. It's a hassle to write, and if
> an user decides to set multiple use flags on such a virtual, why
> not just let him do it?
> 

This is something that should only be done on a case-by-case basis, as
needed -- for instance, with virtual/krb5 only one provider can be
installed at a time as they block eachother.

We could leave it up to portage to error on mit-krb5 and heimdal being
forced into the installation despite blocking eachother, but i think
portage would have a better chance telling end-users about the
conflict (and maybe helping to resolve it better via --autounmask?) if
there was a REQUIRED_USE.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPSrsMACgkQ2ugaI38ACPB6NgD+NK2m8iM46YMi9kITUFEIQ/ih
J67PjULbQ5ZHDRQDUs4A/ik+XNbsjNQwFd08jMD1dVG0DLr7VRVvUGz1VpmQB7so
=Myry
-----END PGP SIGNATURE-----

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

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

On Fri, 25 Jul 2014 15:23:47 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> This is something that should only be done on a case-by-case basis, as
> needed -- for instance, with virtual/krb5 only one provider can be
> installed at a time as they block eachother.
> 
> We could leave it up to portage to error on mit-krb5 and heimdal being
> forced into the installation despite blocking eachother, but i think
> portage would have a better chance telling end-users about the
> conflict (and maybe helping to resolve it better via --autounmask?) if
> there was a REQUIRED_USE.

Okay, I didn't think of that. I'm not sure if the blocker deps or the
REQUIRED_USE would be more helpful for Portage, but generally I think
that the REQUIRED_USE error message is quite hard to understand for
unexperienced users -- much more so than the error generated by a
blocker dep.

"
   The following REQUIRED_USE flag constraints are unsatisfied:
    heimdal? ( !mit-krb5 ) mit-krb5? ( !heimdal )"
"
might be a bit confusing to some people, and remember that constraint
string would grow much longer if there were more providers, as grows
quadratically.


Regards,
Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Fri, 25 Jul 2014 21:44:02 +0200
Luis Ressel <aranea@aixah.de> wrote:
> Okay, I didn't think of that. I'm not sure if the blocker deps or the
> REQUIRED_USE would be more helpful for Portage, but generally I think
> that the REQUIRED_USE error message is quite hard to understand for
> unexperienced users -- much more so than the error generated by a
> blocker dep.

...and the fix for that is to scrap REQUIRED_USE and use pkg_pretend
instead.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/07/14 03:46 PM, Ciaran McCreesh wrote:
> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel <aranea@aixah.de>
> wrote:
>> Okay, I didn't think of that. I'm not sure if the blocker deps or
>> the REQUIRED_USE would be more helpful for Portage, but generally
>> I think that the REQUIRED_USE error message is quite hard to
>> understand for unexperienced users -- much more so than the error
>> generated by a blocker dep.
> 
> ...and the fix for that is to scrap REQUIRED_USE and use
> pkg_pretend instead.
> 

Yep, could do it that way instead.  I'm not tied to any particular
implementation.

Back to the concept, though -- thoughts?  Is it worth the work?
Should it be avoided for whatever reason?  Will it just confuse
end-users?  Am I suggesting a fix for a problem we don't really have?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPStOIACgkQ2ugaI38ACPCZrwD+J7qqH5a1YVsFoIt+UmT9rOLq
TSkd6ai7Eum0MEo6CKsA/3Gsuu9O16rua/LZxeW3i3+qBFufIBDQPqU9YwAyU5lJ
=VMCu
-----END PGP SIGNATURE-----

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

[Pacho Ramos]

El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> On Fri, 25 Jul 2014 21:44:02 +0200
> Luis Ressel <aranea@aixah.de> wrote:
> > Okay, I didn't think of that. I'm not sure if the blocker deps or the
> > REQUIRED_USE would be more helpful for Portage, but generally I think
> > that the REQUIRED_USE error message is quite hard to understand for
> > unexperienced users -- much more so than the error generated by a
> > blocker dep.
> 
> ...and the fix for that is to scrap REQUIRED_USE and use pkg_pretend
> instead.
> 

Could you give an example to let us see how pkg_pretend could be used to
achieve the same as REQUIRED_USE?

Thanks

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/07/14 03:51 PM, Pacho Ramos wrote:
> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
>> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel <aranea@aixah.de>
>> wrote:
>>> Okay, I didn't think of that. I'm not sure if the blocker deps
>>> or the REQUIRED_USE would be more helpful for Portage, but
>>> generally I think that the REQUIRED_USE error message is quite
>>> hard to understand for unexperienced users -- much more so than
>>> the error generated by a blocker dep.
>> 
>> ...and the fix for that is to scrap REQUIRED_USE and use
>> pkg_pretend instead.
>> 
> 
> Could you give an example to let us see how pkg_pretend could be
> used to achieve the same as REQUIRED_USE?
> 
> Thanks
> 
> 

pkg_pretend() {
	if use heimdal && use mit-krb5; then
		eerror "Please set only one of the use following flags:"
		eerror "heimdal, mit-krb5"
		die "conflicting use flags set"
	fi
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPStg0ACgkQ2ugaI38ACPDSMQD/UfMayFMJPP3VqzEvR5IwbBjX
w3/JiWDgm6NcYnU+ZTUBAIACTI52ZJn+TUvxWHHwggEv1+ThwIAp5rOIUUl68fce
=MX30
-----END PGP SIGNATURE-----

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

[Pacho Ramos]

El vie, 25-07-2014 a las 15:54 -0400, Ian Stakenvicius escribió:
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel <aranea@aixah.de>
> >> wrote:
> >>> Okay, I didn't think of that. I'm not sure if the blocker deps
> >>> or the REQUIRED_USE would be more helpful for Portage, but
> >>> generally I think that the REQUIRED_USE error message is quite
> >>> hard to understand for unexperienced users -- much more so than
> >>> the error generated by a blocker dep.
> >> 
> >> ...and the fix for that is to scrap REQUIRED_USE and use
> >> pkg_pretend instead.
> >> 
> > 
> > Could you give an example to let us see how pkg_pretend could be
> > used to achieve the same as REQUIRED_USE?
> > 
> > Thanks
> > 
> > 
> 
> pkg_pretend() {
> 	if use heimdal && use mit-krb5; then
> 		eerror "Please set only one of the use following flags:"
> 		eerror "heimdal, mit-krb5"
> 		die "conflicting use flags set"
> 	fi
> }

Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I
guess it was for simplifying ebuilds?

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Fri, 25 Jul 2014 22:12:53 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I
> guess it was for simplifying ebuilds?

It was a historical mistake: originally we were going to use
pkg_pretend for this. But claims were made that this would break some
mythical auto-building systems, and that something machine-readable was
needed. Unfortunately the Council bought this, and put through
REQUIRED_USE without a reference implementation.

Needless to say, the end result is something that isn't human-readable,
and isn't used by any mythical auto-building systems.

(Incidentally, Exherbo has a both human- and machine-readable
implementation, which *is* used by an auto-building system, but the
syntax won't meet Gentoo approval...)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Pacho Ramos]

El vie, 25-07-2014 a las 21:18 +0100, Ciaran McCreesh escribió:
> On Fri, 25 Jul 2014 22:12:53 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Ah, ok, I was wondering why REQUIRED_USE was implemented then :/, I
> > guess it was for simplifying ebuilds?
> 
> It was a historical mistake: originally we were going to use
> pkg_pretend for this. But claims were made that this would break some
> mythical auto-building systems, and that something machine-readable was
> needed. Unfortunately the Council bought this, and put through
> REQUIRED_USE without a reference implementation.
> 
> Needless to say, the end result is something that isn't human-readable,
> and isn't used by any mythical auto-building systems.
> 
> (Incidentally, Exherbo has a both human- and machine-readable
> implementation, which *is* used by an auto-building system, but the
> syntax won't meet Gentoo approval...)
> 

Maybe REQUIRED_USE could allow us to set an error message for each line
to allow us to instruct PMs about what message should they who to the
users :/ (it would show our message that should be more clear, a bit
like we are able to do with "die 'message'")

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/07/14 04:12 PM, Pacho Ramos wrote:
> El vie, 25-07-2014 a las 15:54 -0400, Ian Stakenvicius escribió:
>> On 25/07/14 03:51 PM, Pacho Ramos wrote:
>>> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh
>>> escribió:
>>>> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
>>>> <aranea@aixah.de> wrote:
>>>>> Okay, I didn't think of that. I'm not sure if the blocker
>>>>> deps or the REQUIRED_USE would be more helpful for Portage,
>>>>> but generally I think that the REQUIRED_USE error message
>>>>> is quite hard to understand for unexperienced users -- much
>>>>> more so than the error generated by a blocker dep.
>>>> 
>>>> ...and the fix for that is to scrap REQUIRED_USE and use 
>>>> pkg_pretend instead.
>>>> 
>>> 
>>> Could you give an example to let us see how pkg_pretend could
>>> be used to achieve the same as REQUIRED_USE?
>>> 
>>> Thanks
>>> 
>>> 
>> 
>> pkg_pretend() { if use heimdal && use mit-krb5; then eerror
>> "Please set only one of the use following flags:" eerror
>> "heimdal, mit-krb5" die "conflicting use flags set" fi }
> 
> Ah, ok, I was wondering why REQUIRED_USE was implemented then :/,
> I guess it was for simplifying ebuilds?
> 
> 


REQUIRED_USE came first, pkg_pretend came later, iirc.  In theory,
REQUIRED_USE could have made a nice interactive way to resolve use
conflicts, it just never did.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPSyG4ACgkQ2ugaI38ACPC07wD/VnEG/w0nvYlNsVJszyPXgK0l
Z9YZ3zWOeMffAJiM7NQBAI8x5G5+EXgCrd8gGAA20ENZ5RIuN6qJoE1INRY6x84+
=6L9c
-----END PGP SIGNATURE-----

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Fri, 25 Jul 2014 17:13:18 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> REQUIRED_USE came first, pkg_pretend came later, iirc.  In theory,
> REQUIRED_USE could have made a nice interactive way to resolve use
> conflicts, it just never did.

Nope. pkg_pretend came first, and had an implemented and user-tested
prototype. REQUIRED_USE was shoehorned in at the last minute without an
implementation.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Fri, Jul 25, 2014 at 03:54:53PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 25/07/14 03:51 PM, Pacho Ramos wrote:
> > El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh escribió:
> >> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel <aranea@aixah.de>
> >> wrote:
> >>> Okay, I didn't think of that. I'm not sure if the blocker deps
> >>> or the REQUIRED_USE would be more helpful for Portage, but
> >>> generally I think that the REQUIRED_USE error message is quite
> >>> hard to understand for unexperienced users -- much more so than
> >>> the error generated by a blocker dep.
> >> 
> >> ...and the fix for that is to scrap REQUIRED_USE and use
> >> pkg_pretend instead.
> >> 
> > 
> > Could you give an example to let us see how pkg_pretend could be
> > used to achieve the same as REQUIRED_USE?
> > 
> > Thanks
> > 
> > 
> 
> pkg_pretend() {
> 	if use heimdal && use mit-krb5; then
> 		eerror "Please set only one of the use following flags:"
> 		eerror "heimdal, mit-krb5"
> 		die "conflicting use flags set"
> 	fi
> }

I think this could get complicated really quick though.
For example, if I have an ebuild with three use flags,
flag1/flag2/flag3 with the requirement that one and only one of them
must be set, unless bash has an xor operator I don't know about, that
is going to need a lot of nesting etc to get right.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Fri, 25 Jul 2014 16:23:23 -0500
William Hubbs <williamh@gentoo.org> wrote:
> I think this could get complicated really quick though.
> For example, if I have an ebuild with three use flags,
> flag1/flag2/flag3 with the requirement that one and only one of them
> must be set, unless bash has an xor operator I don't know about, that
> is going to need a lot of nesting etc to get right.

You don't want xor. You want addition.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote:
> On Fri, 25 Jul 2014 16:23:23 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> > I think this could get complicated really quick though.
> > For example, if I have an ebuild with three use flags,
> > flag1/flag2/flag3 with the requirement that one and only one of them
> > must be set, unless bash has an xor operator I don't know about, that
> > is going to need a lot of nesting etc to get right.
> 
> You don't want xor. You want addition.

Can you show an example?

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Fri, 25 Jul 2014 16:46:07 -0500
William Hubbs <williamh@gentoo.org> wrote:
> On Fri, Jul 25, 2014 at 10:25:57PM +0100, Ciaran McCreesh wrote:
> > On Fri, 25 Jul 2014 16:23:23 -0500
> > William Hubbs <williamh@gentoo.org> wrote:
> > > I think this could get complicated really quick though.
> > > For example, if I have an ebuild with three use flags,
> > > flag1/flag2/flag3 with the requirement that one and only one of
> > > them must be set, unless bash has an xor operator I don't know
> > > about, that is going to need a lot of nesting etc to get right.
> > 
> > You don't want xor. You want addition.
> 
> Can you show an example?

Well, if the use flag is on, you count it as 1, and if it's off, you
count it as 0. Then "need at least one" is just "the sum of these values
is at least 1", and "need exactly one" is "the sum of these values is
exactly 1".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/25/2014 05:23 PM, William Hubbs wrote:
> On Fri, Jul 25, 2014 at 03:54:53PM -0400, Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 25/07/14 03:51 PM, Pacho Ramos wrote:
>>> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh
>>> escribió:
>>>> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
>>>> <aranea@aixah.de> wrote:
>>>>> Okay, I didn't think of that. I'm not sure if the blocker
>>>>> deps or the REQUIRED_USE would be more helpful for Portage,
>>>>> but generally I think that the REQUIRED_USE error message
>>>>> is quite hard to understand for unexperienced users -- much
>>>>> more so than the error generated by a blocker dep.
>>>> 
>>>> ...and the fix for that is to scrap REQUIRED_USE and use 
>>>> pkg_pretend instead.
>>>> 
>>> 
>>> Could you give an example to let us see how pkg_pretend could
>>> be used to achieve the same as REQUIRED_USE?
>>> 
>>> Thanks
>>> 
>>> 
>> 
>> pkg_pretend() { if use heimdal && use mit-krb5; then eerror
>> "Please set only one of the use following flags:" eerror
>> "heimdal, mit-krb5" die "conflicting use flags set" fi }
> 
> I think this could get complicated really quick though. For
> example, if I have an ebuild with three use flags, 
> flag1/flag2/flag3 with the requirement that one and only one of
> them must be set, unless bash has an xor operator I don't know
> about, that is going to need a lot of nesting etc to get right.
> 
> William
> 

If you want to say "At most one of the flags 'foo', 'bar', and 'baz'
may be selected", then you say it like so (requires EAPI=5):

REQUIRED_USE="?? ( foo bar baz )"

If you want to say "Exactly one of the flags ...", then you use:

REQUIRED_USE="^^ ( foo bar baz )"

And, as always, you can say "At least one of the flags ..." with:

REQUIRED_USE="|| ( foo bar baz )"

While each of these can be written using the "foo? ( !bar )"-type
primitives, the messages portage outputs are generally better with
'??', '^^', and '||', as you might see something like:

"
   The following REQUIRED_USE flag constraints are unsatisfied:
     at-most-one-of ( foo bar baz )
"

Which is, in my opinion, more readable.

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJT0+lKAAoJELHSF2kinlg4T8sQAKLq2d4x8UfDTxm8FP6yX5zv
g0GGjPe6TNSwJT83FIw2Bof85u2xGUHaozUaxr+3wwgYVmSaH8BcuEc41reaNZu0
aRhFonAySSTVW/OFEW/X+kpfxAgtFAVGsZ2MBXuFLshB+z/OPDL4lPS7pvUCSZVG
iXPlLNE05ZvF+mxSU4enKEChRPxYTBso3cXGqog0qAZrefv8I9w+QeesaGvXlr7v
65S9qPcgOhQRz1q5HfoQ55fdGHy53+/9ny86Gpxpg7xbEYUe0t2LCInFPT4ivL28
OAnSbwML7bMzphvT4EM+eHghfWIATRmnY5O7O9X66sOUB/JrtG3eQei/9EyAHwhA
JurcdfUu8zcsSjocuqxbQpMGeiEa1bcfzl3u39WUuFAoVsayzXEI3U9SziemmCpU
CCeRF+A5mV6PhFQBYczkdeu3xKc9zQoA3s/EaUYybmTli4oVwtMJUm224TWJEFg+
d7AxM49dyRPLHrHxbK69G7RVowXlaPlISCA/hahAmcgtZVD8y1phwP1qB9j8OBlL
DTrcuqiv9Ba4J+DmdhsjB/uvVZpoyfMVl9z1ytLKFjiEpo/PyJAPWRlRrAwq/Gz8
1rh4MrSqAEMGB4mEQaohDfMVVaCQmhGXZkpaBMtARiV3BDlI3W0bKPPh+r435ZZc
Z7PHHOimf/6acsprx/wI
=vExv
-----END PGP SIGNATURE-----

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On Sat, Jul 26, 2014 at 01:45:46PM -0400, Jonathan Callen wrote:
 
 *snip*

> If you want to say "At most one of the flags 'foo', 'bar', and 'baz'
> may be selected", then you say it like so (requires EAPI=5):
> 
> REQUIRED_USE="?? ( foo bar baz )"
> 
> If you want to say "Exactly one of the flags ...", then you use:
> 
> REQUIRED_USE="^^ ( foo bar baz )"
> 
> And, as always, you can say "At least one of the flags ..." with:
> 
> REQUIRED_USE="|| ( foo bar baz )"
> 
> While each of these can be written using the "foo? ( !bar )"-type
> primitives, the messages portage outputs are generally better with
> '??', '^^', and '||', as you might see something like:
> 
> "
>    The following REQUIRED_USE flag constraints are unsatisfied:
>      at-most-one-of ( foo bar baz )
> "
> 
> Which is, in my opinion, more readable.

Now I understand what ciaranm was suggesting in pkg_pretend. Note, this
is not shell syntax, but it conveys the idea...

pkg_pretend() {
	count=0
	for x in foo bar bas; do
		use $x && count += 1
	done
	# Now, if count == 0 none of the flags are used, and
	# if count > 1 more than one is used, so die whenever appropriate
	# with any error message you choose.
}

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Dnia 2014-07-25, o godz. 14:49:44
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> +REQUIRED_USE="heimdal? ( !mit-krb5 )
> +       mit-krb5? ( !heimdal )"

Did you mean:

REQUIRED_USE="^^ ( heimdal mit-krb5 )"

?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/07/14 04:41 PM, Michał Górny wrote:
> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@gentoo.org>
> napisał(a):
> 
>> +REQUIRED_USE="heimdal? ( !mit-krb5 ) +       mit-krb5? (
>> !heimdal )"
> 
> Did you mean:
> 
> REQUIRED_USE="^^ ( heimdal mit-krb5 )"
> 
> ?
> 


Nope, that requires one or the other to be set.  If users don't care,
they shouldn't have to set one at all.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPSx5cACgkQ2ugaI38ACPCJQgD/TxYSU4AUzGWqEmG/Y+rM50Jr
4m25kOPR+DCp17Gr4SIA/1lu1gBm4fL/ZwDXe5lpy0N+FZmJjhdB0guhJGGieH7S
=pMB6
-----END PGP SIGNATURE-----

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

[justin]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On 25/07/14 23:09, Ian Stakenvicius wrote:
> On 25/07/14 04:41 PM, Michał Górny wrote:
>> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@gentoo.org>
>> napisał(a):
> 
>>> +REQUIRED_USE="heimdal? ( !mit-krb5 ) +       mit-krb5? (
>>> !heimdal )"
> 
>> Did you mean:
> 
>> REQUIRED_USE="^^ ( heimdal mit-krb5 )"
> 
>> ?
> 
> 
> 
> Nope, that requires one or the other to be set.  If users don't care,
> they shouldn't have to set one at all.
> 
> 


REQUIRED_USE="?? ( heimdal mit-krb5 )" from EAPI=5 would do that.

"""
REQUIRED_USE supports new at-most-one-of operator

The new at-most-one-of operator consists of the string '??', and is
satisfied if zero or one (but no more) of its child elements is matched.
"""

Justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1024 bytes --]

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

[Duncan]

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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)

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

Dnia 2014-07-26, o godz. 08:05:32
Duncan <1i5t5.duncan@cox.net> napisał(a):

> 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.

USE_EXPAND are global by definition. We ought fight with the abuse of
USE_EXPAND rather than make another abuse legitimate. Especially that
you're going to increase a lot of new variables quickly for no really
good reason.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Duncan]

Michał Górny posted on Sat, 26 Jul 2014 10:53:21 +0200 as excerpted:

> USE_EXPAND are global by definition. We ought fight with the abuse of
> USE_EXPAND rather than make another abuse legitimate. Especially that
> you're going to increase a lot of new variables quickly for no really
> good reason.

Well, USE flags are global by definition, unless set differently in 
package.use, as well.

And if pacho's single VIRTUAL use-expand variable idea is taken, that's 
only one instead of the many in my proposal.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

On Sat, 26 Jul 2014 10:53:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> USE_EXPAND are global by definition.

Naah. They're global by a Portage configuration file limitation. In the
old days, USE flags were global too...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Duncan]

Duncan posted on Sat, 26 Jul 2014 08:05:32 +0000 as excerpted:

> 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.
> 
> What about handling each such virtual_USE as a USE_EXPAND?

> [Example] VIRTUAL_KRB5

Hmm, thinking toward implementation, what about a virtual.eclass, 
inherited by virtuals?

It could even have a declarative interface, such that from 
virtual/krb5-0.ebuild (I've left out the minversion and multilib-usedep 
stuff here as the example above did as well, but it could be passed 
too)...

inherit virtual
VIRTUAL_EXCLUSIVE="app-crypt/mit-krb5 app-crypt/heimdal"

... would setup most of the basics for an exclusive virtual, including 
the VIRTUAL_KRB5 USE_EXPAND name (based on $PN), the two providers and 
rdepends, the fact that they're exclusive and thus a default pkg_pretend 
or required_use, etc.

In for instance virtual/editors, this could be used in place of its 
current RDEPEND:

VIRTUAL_MULTI="
	app-editors/nano
	app-editors/dav
	app-editors/e3
	...
	mail-client/alpine[-onlyalpine]
	sys-apps/ed
"

With an eclass, the default pkg_pretend for exclusive-virtuals would be 
standardized, standardizing the error message and explanation for it as 
well, giving it a chance to be a bit more informative than unstandardized 
one-offs might tend to be.

Of course the same eclass idea could be used with simple USE flags as 
well, but I prefer the USE_EXPANDs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/07/14 04:05 AM, Duncan wrote:
> 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.
> 


*shrug*, sure..  effectively we just start using
IUSE="virtual_krb5_mit-krb5" instead of "mit-krb5" but yes this would
work too.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPTrbUACgkQ2ugaI38ACPAbcAD/VapV0WR+Z7aWcyHeehHzoHSw
Qi8o+EDkQpakD3bVVtAA/0WSTPsPmVWHq3Fn0iITXbprHsKWMV+mXPN23nbpUdzf
=aE4s
-----END PGP SIGNATURE-----

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

[Manuel Rüger]

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1016 bytes --]

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

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

Manuel Rüger wrote:
> 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,

You should know that it's the other way around. freebsd-lib isn't to
blame, but >=dev-libs/libusb-1.0.18 is.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

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

[Ian Stakenvicius]

-----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-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4298 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ian Stakenvicius]

-----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
> <axs@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-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

Dnia 2014-07-25, o godz. 14:49:44
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> 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.

I think I don't get this argument.

If you really want to have a particular provider for the virtual for
external purposes, it's fully purposeful to put it in @world or
otherwise in a custom set. In this case, USE flags aren't helpful.

If you only prefer a particular provider, you can tip portage easily to
use it without resorting to USE flags. This also allows portage to
semi-transparently switch to other provider if dependencies need it.
In this case, USE flags only make this auto-switching harder.

> 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).

While I agree that finding some solution is a good step forward, I'm
afraid this doesn't really lead us anywhere. Even if it allows to
workaround the actual portage issue, I'm afraid we will hit it again
somewhere else. Shortly, Gentoo would be full of workarounds... oh
wait, it already is.

By the way, proper virtuals for krb5 would involve much more crazy
stuff to get slot operator right. And then Ciaran would yell at us for
abusing slots.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/07/14 07:21 AM, Michał Górny wrote:
> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@gentoo.org>
> napisał(a):
> 
>> 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.
> 
> I think I don't get this argument.
> 
> If you really want to have a particular provider for the virtual
> for external purposes, it's fully purposeful to put it in @world
> or otherwise in a custom set. In this case, USE flags aren't
> helpful.

The argument I was trying to make is that USE flags would allow
end-users to accomplish the same thing, while not having an entry in
@world and therefore allowing the package to be --depclean'ed if the
virtual is --depcleaned.

I personally don't use sets so i've no idea if the exact same thing
could be accomplished in sets; for some reason i don't think so.


> 
> If you only prefer a particular provider, you can tip portage
> easily to use it without resorting to USE flags. This also allows
> portage to semi-transparently switch to other provider if
> dependencies need it. In this case, USE flags only make this
> auto-switching harder.

That is the other part of this idea, to make auto-switching harder,
because right now portage likes to auto-switch even when it seems like
it shouldn't.

I figure this idea would also help with Ciaran's wishlist item of ||()
deps becoming more strictly-controlled and readily deterministic.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPWgi8ACgkQ2ugaI38ACPBfoQD/bZmCxCdLM9EyeJRrst5QmD9X
NS2Y0HCNhRnCfAuplUYA/2UHibYB6YHdKOi40RkWOUA0KMTRSwXYPR6dYsmByiQL
=njwB
-----END PGP SIGNATURE-----

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

[James Potts]

On Mon, Jul 28, 2014 at 12:02 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 28/07/14 07:21 AM, Michał Górny wrote:
>> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@gentoo.org>
>> napisał(a):
>>
>>> 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.
>>
>> I think I don't get this argument.
>>
>> If you really want to have a particular provider for the virtual
>> for external purposes, it's fully purposeful to put it in @world
>> or otherwise in a custom set. In this case, USE flags aren't
>> helpful.
>
> The argument I was trying to make is that USE flags would allow
> end-users to accomplish the same thing, while not having an entry in
> @world and therefore allowing the package to be --depclean'ed if the
> virtual is --depcleaned.
>
> I personally don't use sets so i've no idea if the exact same thing
> could be accomplished in sets; for some reason i don't think so.
>
>
>>
>> If you only prefer a particular provider, you can tip portage
>> easily to use it without resorting to USE flags. This also allows
>> portage to semi-transparently switch to other provider if
>> dependencies need it. In this case, USE flags only make this
>> auto-switching harder.
>
> That is the other part of this idea, to make auto-switching harder,
> because right now portage likes to auto-switch even when it seems like
> it shouldn't.
>
> I figure this idea would also help with Ciaran's wishlist item of ||()
> deps becoming more strictly-controlled and readily deterministic.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iF4EAREIAAYFAlPWgi8ACgkQ2ugaI38ACPBfoQD/bZmCxCdLM9EyeJRrst5QmD9X
> NS2Y0HCNhRnCfAuplUYA/2UHibYB6YHdKOi40RkWOUA0KMTRSwXYPR6dYsmByiQL
> =njwB
> -----END PGP SIGNATURE-----
>
Also, what about the case where multiple providers for the same
virtual are installed but the first doesn't satisfy the dependency?
Currently, portage only looks at the installed state of the providers,
in order, and will use the first installed provider it finds even if
it doesn't actually satisfy the dependency (e.g. due to use deps) and
the dependency is already satisfied by a different installed provider.
Paludis has an elegant solution for this situation (-F/-A), but afaik
portage doesn't.  Use flags in virtuals would solve this without
having to hack around in portage and have it check all possible deps
before choosing one.

--James

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Mon, 28 Jul 2014 23:23:04 -0500
James Potts <arek75@gmail.com> wrote:
> Paludis has an elegant solution for this situation (-F/-A), but afaik
> portage doesn't.

I'd not call -F / -A elegant... It's a nasty trick that we only added
because || dependencies are such a pain. They shouldn't be necessary.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

Dnia 2014-07-28, o godz. 13:02:39
Ian Stakenvicius <axs@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 28/07/14 07:21 AM, Michał Górny wrote:
> > Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius <axs@gentoo.org>
> > napisał(a):
> > 
> >> 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.
> > 
> > I think I don't get this argument.
> > 
> > If you really want to have a particular provider for the virtual
> > for external purposes, it's fully purposeful to put it in @world
> > or otherwise in a custom set. In this case, USE flags aren't
> > helpful.
> 
> The argument I was trying to make is that USE flags would allow
> end-users to accomplish the same thing, while not having an entry in
> @world and therefore allowing the package to be --depclean'ed if the
> virtual is --depcleaned.

If you need it externally, you need it not depcleaned, obviously. So
you have to have something in @world. If you need a specific
implementation, it's more elegant to put that in @world rather than
the virtual and playing with USE flags.

> > If you only prefer a particular provider, you can tip portage
> > easily to use it without resorting to USE flags. This also allows
> > portage to semi-transparently switch to other provider if
> > dependencies need it. In this case, USE flags only make this
> > auto-switching harder.
> 
> That is the other part of this idea, to make auto-switching harder,
> because right now portage likes to auto-switch even when it seems like
> it shouldn't.

This is a bug in portage and should be fixed there. As I said, working
it around will only fix it for one package, and it will happen again
and again, possibly in cases harder to pinpoint.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]