Michał Górny wrote:
> On Thu, 21 Jun 2012 20:05:46 +0100
> David Leverton <levertond@...> wrote:
>> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
>> should REQUIRED_USE be re-verified:
>>
>> a) for every dep resolution
>> b) when the package is involved in the resolution for some other
>> reason (not necessarily being reinstalled, just when the resolver has
>> some reason to look at it)
>> c) something else?
>
> Well, I don't understand the difference between a) and b) in your case

Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and 
that I have it installed and then modify one of the flags it uses in my 
configuration, but don't run any PM commands.  Then suppose I install a 
Gnome package.  Normally installing a Gnome package wouldn't require the 
PM to go anywhere near kde-meta, but being strict about revalidating 
REQUIRED_USE would require it to look through every installed package, 
just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every 
installation command.  Is that necessary?

 > but the idea is that REQUIRED_USE should be re-verified if either
 > enabled USE flag list or REQUIRED_USE changes.

Would that mean the enabled USE flag list should be updated in the VDB 
every time REQUIRED_USE is checked, even when the package isn't being 
reinstalled?  I think it would probably be easier to just recheck 
REQUIRED_USE, without trying to figure out whether any of the 
IUSE_RUNTIME flags were changed, it's just a question of how eager we 
want to be.

>> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
>> of package B being disabled, but it's unlikely to be useful.  To make
>> this more concrete, a fictional but vaguely plausible example:

>> Possible solutions:
>>
>> a) automatically rewrite the dep as
>>       postscript? ( app-text/ghostscript )
>>       !postscript? ( !app-text/ghostscript )
>> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
>> sense in that case to disallow them in !foo-style conditionals in the
>> dependencies of the package itself, as that could cause similar
>> paradoxes)
 >> c) don't address it in the spec itself, and require people
>> to manually write the dep in the blocker form if it's required
>> d) something else?

> Good observation. I think b) is the best solution since forced removal
> of random dependencies is a very bad idea (and misuse of blockers).

One case that I forgot to mention before: if some package does something 
like

     if has_version app-text/docmangler[postscript]; then
         # ...
     else
         # ...
     fi

Here, again, the "else" branch can lead to incoherent results as it 
can't assume that the postscript flag being disabled means Ghostscript 
isn't installed, and this one can't be forbidden by restricting the 
allowed dep forms.  I think we'd have to just say "don't do that then"....