On Tue, Sep 18, 2012 at 06:04:51AM +0200, Arfrever Frehtes Taifersar Arahesis 
wrote:
> A potential dev-libs/dep package

I assume this is a hypothetical package; if this is something out of 
your personal eapi/repo, please state so.

> might have valid use case for USE flags related to USE_EXPAND="DEP".
> Your suggested syntax for types of dependencies in DEPENDENCIES would 
> conflict with these USE flags
> after implementing ":" delimiter for USE_EXPAND-related USE flags.

Actually, that was both the intent, and I thought explicitly 
clear/documented; 'dep' would be a PM controlled namespace- as I'm 
pretty sure I stated in the doc, else in that email thread on the 
subject.

Thus, yep, you got me, you can't create a USE_EXPAND/USE_GROUP named 
'dep'.

I very, very strongly doubt that anyone ever would come up with a 
scenario where this is required, and the alternative name is somehow 
worse.  Please give examples.

Also, you should keep in mind that w/ what I ultimately want for 
USE_EXPAND, we'd have a couple other namespace that couldn't be used 
by ebuilds/profiles.

Top of the head,

* arch; kind of a given, alternate addressing of x86 via arch:x86.  
Would be added purely for consistency, although iteration of the 
potential values would warrant the group existing.

* use; same reasoning as arch, added for consistency so the consuming 
code doesn't have to special case things.

* phase; intentionally reserved should we ever decide to do per phase 
restrict control (aka, turning userpriv off just for the test phase).

* license; Now, this one I *am* spitballing a bit- I'm not proposing 
it, just frankly thinking out loud.  If we had a license namespace 
there, we could potentially mask out certain deps if the user 
requested say pure bsd, or as a potential way to properly integrate in 
our existing bindist support; keep in mind if the group existed, we 
could use it in REQUIRED_USE also.


Either way, you get the idea; it was explicit that in fixing 
use_expand, a few namespaces would be offlimits.


> I vote for a separate syntax for types of dependencies.

A separate syntax, or keeping dep:build? from conflicting w/ someone 
wanting to use USE_EXPAND="DEP" ?

If you've got other critiques state them, else, while your opinion is 
yours, I doubt anyone is going to agree with you that it's a deal 
breaker.

~harring

Reply via email to