Michał Górny wrote:
On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton <levert...@googlemail.com> 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"....
