1 |
On do, 2012-06-21 at 20:05 +0100, David Leverton wrote: |
2 |
> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, |
3 |
> should REQUIRED_USE be re-verified: |
4 |
> |
5 |
> a) for every dep resolution |
6 |
> b) when the package is involved in the resolution for some other reason |
7 |
> (not necessarily being reinstalled, just when the resolver has some |
8 |
> reason to look at it) |
9 |
> c) something else? |
10 |
> |
11 |
> I think b) should be sufficient (and probably easier to implement), but |
12 |
> is there any reason why it wouldn't be? |
13 |
|
14 |
I would still prefer for the resolver to not treat such packages |
15 |
specially at all, and to just deal with USE flag changes explicitly the |
16 |
same way they're dealt with for "normal" packages/flags, just skipping |
17 |
the actual rebuild and reinstall steps (just updating the vdb). This |
18 |
sidesteps problems like this one completely. If the package manager |
19 |
folks think they can safely do something smarter here that might be |
20 |
nice, but the feature still seems useful (in reducing the number of |
21 |
silly rebuilds) and far easier to understand without such magic. |
22 |
|
23 |
This also means things like has_version checks work exactly like they do |
24 |
right now. |
25 |
|
26 |
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of |
27 |
> package B being disabled, but it's unlikely to be useful. To make this |
28 |
> more concrete, a fictional but vaguely plausible example: |
29 |
> |
30 |
> app-text/docmangler: |
31 |
> |
32 |
> # links to poppler to handle PDFs, and can use Ghostscript for |
33 |
> # PostScript support if available |
34 |
> IUSE="postscript" |
35 |
> IUSE_RUNTIME="postscript" |
36 |
> DEPEND="app-text/poppler" |
37 |
> RDEPEND="${DEPEND} |
38 |
> postscript? ( app-text/ghostscript )" |
39 |
> |
40 |
> app-misc/coolapp: |
41 |
> |
42 |
> IUSE="doc" |
43 |
> # if Ghostscript is installed, docmangler uses it for both |
44 |
> # PostScript and PDF files, but Ghostscript misrenders our PDFs |
45 |
> DEPEND="doc? ( app-text/docmangler[-postscript] )" |
46 |
> |
47 |
> Here, the [-postscript] dep would force the user to disable that flag, |
48 |
> but it wouldn't do much good because Ghostscript would still be |
49 |
> installed. This doesn't happen with regular USE flags because (if the |
50 |
> ebuild is written correctly) disabling the flag removes the feature even |
51 |
> if its dependencies happen to be installed. |
52 |
> |
53 |
> Possible solutions: |
54 |
> |
55 |
> a) automatically rewrite the dep as |
56 |
> postscript? ( app-text/ghostscript ) |
57 |
> !postscript? ( !app-text/ghostscript ) |
58 |
|
59 |
There may be more than one version of docmangler, with a postscript flag |
60 |
with different effects (IUSE_RUNTIME or full IUSE, different |
61 |
dependencies). That means this kind of rewriting would have to be done |
62 |
based on the dependencies of the docmangler installed at the time this |
63 |
package gets built, which seems like entirely too much magic, and... |
64 |
|
65 |
> b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make |
66 |
> sense in that case to disallow them in !foo-style conditionals in the |
67 |
> dependencies of the package itself, as that could cause similar paradoxes) |
68 |
|
69 |
this seems generally impossible, as the same USE flag may be |
70 |
IUSE_RUNTIME in only some versions of docmangler. |
71 |
|
72 |
> c) don't address it in the spec itself, and require people to manually |
73 |
> write the dep in the blocker form if it's required |
74 |
|
75 |
I would be in favor of leaving this up to the writer of the coolapp |
76 |
ebuild, especially as if docmangler is currently using a "full" USE flag |
77 |
for postscript this is already currently broken. It seems coolapp should |
78 |
not be building the pdfs, or should be deleting them after they're |
79 |
built, rather than forbidding the user from having a docmangler that can |
80 |
create pdfs (as presumably not *all* generated pdfs are corrupt). |
81 |
|
82 |
I really think this GLEP should be purely about reducing silly rebuilds |
83 |
in packages where it makes sense to USE-depend on them with a flag set, |
84 |
or where an already popular flag can be used to pull in some obvious |
85 |
packages. I think something like "suggested" dependencies can be used to |
86 |
solve a slightly different problem, and perhaps we could have those too, |
87 |
but let's leave those for later. |
88 |
|
89 |
-- |
90 |
Marien Zwart |