On Thu, 21 Jun 2012 21:26:26 +0100
David Leverton <levertond@...> wrote:
> 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
No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).
Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.
> > 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.
No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.
> >> 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
> # ...
> # ...
> 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"....
Well, as I see it restricting is more of a policy than a technical
requirement. But in the current form, the spec doesn't allow passing
IUSE_RUNTIME flags to has_version() so we're on the safe side :P.