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
>> 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
if has_version app-text/docmangler[postscript]; then
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"....