On Thu, 21 Jun 2012 21:26:26 +0100 David Leverton <levert...@googlemail.com> wrote:
> 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? 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 > # ... > 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".... 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. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
