Gentoo Archives: gentoo-dev

From: David Leverton <levertond@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Date: Thu, 21 Jun 2012 20:27:45
Message-Id: 4FE38372.5070700@googlemail.com
In Reply to: Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags by "Michał Górny"
1 Michał Górny wrote:
2 > On Thu, 21 Jun 2012 20:05:46 +0100
3 > David Leverton <levertond@××××××××××.com> wrote:
4 >> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
5 >> should REQUIRED_USE be re-verified:
6 >>
7 >> a) for every dep resolution
8 >> b) when the package is involved in the resolution for some other
9 >> reason (not necessarily being reinstalled, just when the resolver has
10 >> some reason to look at it)
11 >> c) something else?
12 >
13 > Well, I don't understand the difference between a) and b) in your case
14
15 Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and
16 that I have it installed and then modify one of the flags it uses in my
17 configuration, but don't run any PM commands. Then suppose I install a
18 Gnome package. Normally installing a Gnome package wouldn't require the
19 PM to go anywhere near kde-meta, but being strict about revalidating
20 REQUIRED_USE would require it to look through every installed package,
21 just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every
22 installation command. Is that necessary?
23
24 > but the idea is that REQUIRED_USE should be re-verified if either
25 > enabled USE flag list or REQUIRED_USE changes.
26
27 Would that mean the enabled USE flag list should be updated in the VDB
28 every time REQUIRED_USE is checked, even when the package isn't being
29 reinstalled? I think it would probably be easier to just recheck
30 REQUIRED_USE, without trying to figure out whether any of the
31 IUSE_RUNTIME flags were changed, it's just a question of how eager we
32 want to be.
33
34 >> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
35 >> of package B being disabled, but it's unlikely to be useful. To make
36 >> this more concrete, a fictional but vaguely plausible example:
37
38 >> Possible solutions:
39 >>
40 >> a) automatically rewrite the dep as
41 >> postscript? ( app-text/ghostscript )
42 >> !postscript? ( !app-text/ghostscript )
43 >> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
44 >> sense in that case to disallow them in !foo-style conditionals in the
45 >> dependencies of the package itself, as that could cause similar
46 >> paradoxes)
47 >> c) don't address it in the spec itself, and require people
48 >> to manually write the dep in the blocker form if it's required
49 >> d) something else?
50
51 > Good observation. I think b) is the best solution since forced removal
52 > of random dependencies is a very bad idea (and misuse of blockers).
53
54 One case that I forgot to mention before: if some package does something
55 like
56
57 if has_version app-text/docmangler[postscript]; then
58 # ...
59 else
60 # ...
61 fi
62
63 Here, again, the "else" branch can lead to incoherent results as it
64 can't assume that the postscript flag being disabled means Ghostscript
65 isn't installed, and this one can't be forbidden by restricting the
66 allowed dep forms. I think we'd have to just say "don't do that then"....

Replies