1 |
On di, 2012-06-19 at 18:53 +0200, hasufell wrote: |
2 |
> On 06/17/2012 10:31 PM, Michał Górny wrote: |
3 |
> > Hello, |
4 |
> > |
5 |
> > A simple solution to a program long-unsolved. In GLEP form. |
6 |
> > |
7 |
> > Both attached and published as a gist: |
8 |
> > |
9 |
> > https://gist.github.com/2945569 |
10 |
> > |
11 |
> > (please note that github doesn't render GLEP headers correctly) |
12 |
> > |
13 |
> |
14 |
> As already stated I like this idea, because I already got some optional |
15 |
> dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser. |
16 |
> |
17 |
> However I have a few objections: |
18 |
> |
19 |
> 1. Optional deps are SUGGESTIONS from the dev which he considered |
20 |
> nice/good/sane at the time of writing the ebuild. Other people might |
21 |
> totally disagree with those suggestions. |
22 |
> As useflags in IUSE_RUNTIME can pick from global useflags as well or |
23 |
> even set "+foo" the user might have a hard time to turn off things he |
24 |
> does not want without turning them off for regular IUSE as well. |
25 |
|
26 |
I think we're not all agreeing on which problem is being solved here. I |
27 |
see IUSE_RUNTIME as an improvement for packages that have a runtime |
28 |
dependency on another package to provide a certain feature, but no way |
29 |
of turning this feature off at build time. Examples of this kind of |
30 |
dependency are executables or python imports, where the executable or |
31 |
library being absent is dealt with at runtime. For such packages putting |
32 |
the dependency behind a USE flag makes sense, and for other packages to |
33 |
depend on the package with that USE flag set also makes sense. This |
34 |
already works today. However, if you originally built the package with |
35 |
the USE flag off, and now try to install something that depends on the |
36 |
package with the USE flag on, you force a rebuild. That's not so nice, |
37 |
as there's no change to the installed package at all: the rebuild is a |
38 |
waste of time. IUSE_RUNTIME allows the package manager to skip that |
39 |
rebuild, as it now knows it is unnecessary. |
40 |
|
41 |
What you are describing is more like "suggested" dependencies. Those may |
42 |
also be useful, but do not solve quite the same problem. I do not think |
43 |
they quite replace the USE flag-based approach described above, as it |
44 |
makes sense for other ebuilds to depend on "foo with support for feature |
45 |
blah" through the "blah" USE flag without all those other packages |
46 |
having to know which specific dependencies this adds to foo, or whether |
47 |
foo needs a rebuild to enable the feature or not. |
48 |
|
49 |
Also, even in packages in which IUSE_RUNTIME is used for something like |
50 |
"suggested" dependencies it is not terribly hard for the user to turn |
51 |
the USE flag off (package.use) and install the interesting bits by hand. |
52 |
|
53 |
> 2. Afais useflags that are already in IUSE and used for build-time stuff |
54 |
> must not be used for IUSE_RUNTIME too. |
55 |
> This is a random rule IMO. I don't have many cases in mind where this |
56 |
> would be annoying (could think of "debug" enabling some in-source |
57 |
> switches and adding optional debug tools in RDEPEND. Having one flag |
58 |
> here would make it cleaner and tighter for the user to interact with |
59 |
> useflags.). |
60 |
> However... this is not a logical rule, rather a technical issue. If |
61 |
> there is a way to avoid this restriction that would be nice. |
62 |
|
63 |
I do not see where you are going with this. If it makes sense to turn on |
64 |
the build-time support for a feature without installing all the |
65 |
dependencies then the extra dependencies should go behind a separate USE |
66 |
flag (and that separate USE flag may depend on the USE flag controlling |
67 |
the build-time support using REQUIRED_USE). Or perhaps the additional |
68 |
dependencies should be in some new kind of "suggested" depend. |
69 |
|
70 |
> 3. There are no unconditional optional deps possible. |
71 |
> ssuominen had an example: |
72 |
> "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb |
73 |
> in x11-base/xorg-server" |
74 |
|
75 |
I do not see where you are going with this. Can you refer me to where |
76 |
this suggestion was made? virtualx.eclass adds a hard dependency if the |
77 |
test USE flag (or some other USE flag) is set, and no dependency if this |
78 |
USE flag is not set. When would virtualx.eclass add an optional |
79 |
dependency? |
80 |
|
81 |
-- |
82 |
Marien Zwart |