Gentoo Archives: gentoo-dev

From: Marien Zwart <marienz@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Date: Wed, 20 Jun 2012 15:06:45
Message-Id: 1340204734.9532.15.camel@cyclops.marienz.net
In Reply to: Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags by hasufell
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

Replies