1 |
On Thu, 21 Jun 2012 21:26:26 +0100 |
2 |
David Leverton <levertond@××××××××××.com> wrote: |
3 |
|
4 |
> Michał Górny wrote: |
5 |
> > On Thu, 21 Jun 2012 20:05:46 +0100 |
6 |
> > David Leverton <levertond@××××××××××.com> wrote: |
7 |
> >> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, |
8 |
> >> should REQUIRED_USE be re-verified: |
9 |
> >> |
10 |
> >> a) for every dep resolution |
11 |
> >> b) when the package is involved in the resolution for some other |
12 |
> >> reason (not necessarily being reinstalled, just when the resolver |
13 |
> >> has some reason to look at it) |
14 |
> >> c) something else? |
15 |
> > |
16 |
> > Well, I don't understand the difference between a) and b) in your |
17 |
> > case |
18 |
> |
19 |
> Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and |
20 |
> that I have it installed and then modify one of the flags it uses in |
21 |
> my configuration, but don't run any PM commands. Then suppose I |
22 |
> install a Gnome package. Normally installing a Gnome package |
23 |
> wouldn't require the PM to go anywhere near kde-meta, but being |
24 |
> strict about revalidating REQUIRED_USE would require it to look |
25 |
> through every installed package, just in case any have IUSE_RUNTIME |
26 |
> and REQUIRED_USE set, for every installation command. Is that |
27 |
> necessary? |
28 |
|
29 |
No, of course not. Otherwise, every package manager run would |
30 |
practically require it to re-validate all packages in the tree |
31 |
(possibly not only installed ones). |
32 |
|
33 |
Package manager must ensure the flags are valid when package is |
34 |
in the graph. I would think of IUSE_RUNTIME as a last-step action where |
35 |
packages were in the graph for rebuild already but the rebuild is |
36 |
disabled as being unnecessary. |
37 |
|
38 |
> > but the idea is that REQUIRED_USE should be re-verified if either |
39 |
> > enabled USE flag list or REQUIRED_USE changes. |
40 |
> |
41 |
> Would that mean the enabled USE flag list should be updated in the |
42 |
> VDB every time REQUIRED_USE is checked, even when the package isn't |
43 |
> being reinstalled? I think it would probably be easier to just |
44 |
> recheck REQUIRED_USE, without trying to figure out whether any of the |
45 |
> IUSE_RUNTIME flags were changed, it's just a question of how eager we |
46 |
> want to be. |
47 |
|
48 |
No, the USE flag list in vdb may be updated every time the package gets |
49 |
into the graph with changed runtime flags. I don't consider that |
50 |
necessary, however. Just a nice backwards compatibility feature for |
51 |
other applications looking at vdb. |
52 |
|
53 |
> >> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME |
54 |
> >> flag of package B being disabled, but it's unlikely to be useful. |
55 |
> >> To make this more concrete, a fictional but vaguely plausible |
56 |
> >> example: |
57 |
> |
58 |
> >> Possible solutions: |
59 |
> >> |
60 |
> >> a) automatically rewrite the dep as |
61 |
> >> postscript? ( app-text/ghostscript ) |
62 |
> >> !postscript? ( !app-text/ghostscript ) |
63 |
> >> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make |
64 |
> >> sense in that case to disallow them in !foo-style conditionals in |
65 |
> >> the dependencies of the package itself, as that could cause similar |
66 |
> >> paradoxes) |
67 |
> >> c) don't address it in the spec itself, and require people |
68 |
> >> to manually write the dep in the blocker form if it's required |
69 |
> >> d) something else? |
70 |
> |
71 |
> > Good observation. I think b) is the best solution since forced |
72 |
> > removal of random dependencies is a very bad idea (and misuse of |
73 |
> > blockers). |
74 |
> |
75 |
> One case that I forgot to mention before: if some package does |
76 |
> something like |
77 |
> |
78 |
> if has_version app-text/docmangler[postscript]; then |
79 |
> # ... |
80 |
> else |
81 |
> # ... |
82 |
> fi |
83 |
> |
84 |
> Here, again, the "else" branch can lead to incoherent results as it |
85 |
> can't assume that the postscript flag being disabled means |
86 |
> Ghostscript isn't installed, and this one can't be forbidden by |
87 |
> restricting the allowed dep forms. I think we'd have to just say |
88 |
> "don't do that then".... |
89 |
|
90 |
Well, as I see it restricting is more of a policy than a technical |
91 |
requirement. But in the current form, the spec doesn't allow passing |
92 |
IUSE_RUNTIME flags to has_version() so we're on the safe side :P. |
93 |
|
94 |
-- |
95 |
Best regards, |
96 |
Michał Górny |