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".... |