1 |
On 06/20/2012 05:05 PM, Marien Zwart wrote: |
2 |
> On di, 2012-06-19 at 18:53 +0200, hasufell wrote: |
3 |
>> |
4 |
>> 1. Optional deps are SUGGESTIONS from the dev which he considered |
5 |
>> nice/good/sane at the time of writing the ebuild. Other people might |
6 |
>> totally disagree with those suggestions. |
7 |
>> As useflags in IUSE_RUNTIME can pick from global useflags as well or |
8 |
>> even set "+foo" the user might have a hard time to turn off things he |
9 |
>> does not want without turning them off for regular IUSE as well. |
10 |
> |
11 |
> I think we're not all agreeing on which problem is being solved here. I |
12 |
> see IUSE_RUNTIME as an improvement for packages that have a runtime |
13 |
> dependency on another package to provide a certain feature, but no way |
14 |
> of turning this feature off at build time. Examples of this kind of |
15 |
> dependency are executables or python imports, where the executable or |
16 |
> library being absent is dealt with at runtime. For such packages putting |
17 |
> the dependency behind a USE flag makes sense, and for other packages to |
18 |
> depend on the package with that USE flag set also makes sense. |
19 |
|
20 |
Makes sense to you or the developer who wrote the ebuild. |
21 |
I know the usecases of IUSE_RUNTIME, but you have to realize that people |
22 |
might _not_ want additional optional runtime dependencies turned on by |
23 |
useflags that are already in _make.conf_! |
24 |
IUSE_RUNTIME is technically not a seperate thing, cause they go all into |
25 |
IUSE and maintaining useflags might become way more complicated for some |
26 |
users/usecases than it used to be, because of this new feature and a lot |
27 |
more dependencies that are triggered by your USE="..." variable. |
28 |
|
29 |
Something like FEATURES="optional-deps" would simply enable people to |
30 |
have a minimum of dependencies and still be able to use global useflags |
31 |
_without_ micro-managing all of them per-package, cause some of them are |
32 |
in IUSE_RUNTIME and others not. |
33 |
|
34 |
|
35 |
>> 2. Afais useflags that are already in IUSE and used for build-time stuff |
36 |
>> must not be used for IUSE_RUNTIME too. |
37 |
>> This is a random rule IMO. I don't have many cases in mind where this |
38 |
>> would be annoying (could think of "debug" enabling some in-source |
39 |
>> switches and adding optional debug tools in RDEPEND. Having one flag |
40 |
>> here would make it cleaner and tighter for the user to interact with |
41 |
>> useflags.). |
42 |
>> However... this is not a logical rule, rather a technical issue. If |
43 |
>> there is a way to avoid this restriction that would be nice. |
44 |
> |
45 |
> I do not see where you are going with this. If it makes sense to turn on |
46 |
> the build-time support for a feature without installing all the |
47 |
> dependencies then the extra dependencies should go behind a separate USE |
48 |
> flag (and that separate USE flag may depend on the USE flag controlling |
49 |
> the build-time support using REQUIRED_USE). Or perhaps the additional |
50 |
> dependencies should be in some new kind of "suggested" depend. |
51 |
|
52 |
I think it is bad to overuse REQUIRED_USE in that way. REQUIRED_USE |
53 |
blocks the emerge process and should only be used when there is a |
54 |
technical (not logical) useflag correlation. |
55 |
|
56 |
Using a seperate USE flag just because the name is blocked means the |
57 |
user has to look up another useflag and think about what it is for. |
58 |
|
59 |
But as I said... that is rather minor. I just don't like it either, |
60 |
cause I feel it might annoy me in the future. |
61 |
|
62 |
What do you think about useflag expansion and seperating them in |
63 |
make.conf like yngwin suggested: |
64 |
|
65 |
USE_RUNTIME="debug" -> will enable "runtime_debug" useflag for all ebuilds |
66 |
USE="debug" -> will enable "debug" useflag for all ebuilds |
67 |
|
68 |
This would also solve point #1 somehow, cause you don't have to fear |
69 |
that your dependency graph will grow just because you didn't examine all |
70 |
newly introduced IUSE_RUNTIME flags. |
71 |
|
72 |
For people who want that stuff unconditionally they could do: |
73 |
USE_RUNTIME="$USE" |
74 |
|
75 |
and never bother again with it. |
76 |
|
77 |
|
78 |
> |
79 |
>> 3. There are no unconditional optional deps possible. |
80 |
>> ssuominen had an example: |
81 |
>> "virtualx.eclass could have suggestion/recommendation to enable USE=xvfb |
82 |
>> in x11-base/xorg-server" |
83 |
> |
84 |
> I do not see where you are going with this. Can you refer me to where |
85 |
> this suggestion was made? virtualx.eclass adds a hard dependency if the |
86 |
> test USE flag (or some other USE flag) is set, and no dependency if this |
87 |
> USE flag is not set. When would virtualx.eclass add an optional |
88 |
> dependency? |
89 |
> |
90 |
|
91 |
I hope ssuominen might explain more about this idea as I already requested. |