1 |
On Sun, Jun 17, 2012 at 10:31:59PM +0200, Micha?? G??rny wrote: |
2 |
> Hello, |
3 |
> |
4 |
> A simple solution to a program long-unsolved. In GLEP form. |
5 |
> |
6 |
> Both attached and published as a gist: |
7 |
> |
8 |
> https://gist.github.com/2945569 |
9 |
> |
10 |
> (please note that github doesn't render GLEP headers correctly) |
11 |
> |
12 |
> -- |
13 |
> Best regards, |
14 |
> Micha?? G??rny |
15 |
|
16 |
> GLEP: XXX |
17 |
> Title: Optional runtime dependencies via runtime-switchable USE flags |
18 |
> Version: $Revision:$ |
19 |
> Last-Modified: $Date:$ |
20 |
> Author: Micha?? G??rny <mgorny@g.o> |
21 |
> Status: Draft |
22 |
> Type: Standards Track |
23 |
> Content-Type: text/x-rst |
24 |
> Created: 17 Jun 2012 |
25 |
> Post-History: |
26 |
> |
27 |
> |
28 |
> Abstract |
29 |
> ======== |
30 |
> |
31 |
> This GLEP addresses the issue of referencing optional runtime |
32 |
> dependencies in Gentoo packages and ebuilds. It does introduce |
33 |
> a concept of runtime-switchable USE flags to achieve that goal. |
34 |
> |
35 |
> |
36 |
> Motivation |
37 |
> ========== |
38 |
> |
39 |
> Optional runtime dependencies are often found in packages installing |
40 |
> various scripts (shell, python, perl). These are not strictly required |
41 |
> for the particular package to work but installing them enables |
42 |
> additional functionality. |
43 |
> |
44 |
> Unlike in compiled programs, enabling or disabling those features |
45 |
> (dependencies) does not affect the files installed by the package. |
46 |
> They can be installed and uninstalled independently of the package, |
47 |
> resulting in changes of functionality without a need to rebuild |
48 |
> the package. |
49 |
> |
50 |
> Currently such dependencies are usually expressed only through |
51 |
> ``pkg_postinst()`` messages. This forces user to manually install |
52 |
> the necessary dependencies, and uninstall them when they are no longer |
53 |
> necessary. |
54 |
> |
55 |
> Another solution is using regular USE flags. Those flags do not strictly |
56 |
> follow the principles of USE flags because they do not affect files |
57 |
> installed by the package and are not entirely effective to the package |
58 |
> (a disabled feature will still be available if necessary dependency is |
59 |
> installed). Additionally, it requires unnecessary rebuilds |
60 |
> of the package in order to change the dependencies. |
61 |
> |
62 |
> |
63 |
> Specification |
64 |
> ============= |
65 |
> |
66 |
> The ebuilds aiming to provide features enabled through optional runtime |
67 |
> dependencies should: |
68 |
> |
69 |
> 1. create regular USE flags for all those features, following |
70 |
> appropriate specifications for Gentoo ebuilds, and including |
71 |
> the flags in the ``IUSE`` variable; |
72 |
> 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE |
73 |
> flags related to optional runtime dependencies (without prefixes |
74 |
> related to IUSE defaults). |
75 |
> |
76 |
> Additionally, the ebuilds must obey the following rules: |
77 |
> |
78 |
> 1. all flags listed in ``IUSE_RUNTIME`` have to be listed in ``IUSE``, |
79 |
> 2. flags listed in ``IUSE_RUNTIME`` can be referred in ``RDEPEND``, |
80 |
> ``PDEPEND`` and ``REQUIRED_USE`` variables, |
81 |
> 3. flags listed in ``IUSE_RUNTIME`` must not be referred in phase |
82 |
> functions, ``DEPEND`` or ``SRC_URI``, |
83 |
> 4. flags listed in ``IUSE_RUNTIME`` may be referred through USE |
84 |
> dependencies by other packages' ``DEPEND``, ``RDEPEND`` |
85 |
> and ``PDEPEND`` variables. |
86 |
|
87 |
Unless I'm on crack, you're stating that essentially an optional use |
88 |
flag (one you label 'runtime'), is able to be used transitively during |
89 |
DEPEND. That's not particularly "here's some suggested pkgs to |
90 |
install"- that's "rebuild the fucker for this changed DEPEND", which |
91 |
is the existing situation. |
92 |
|
93 |
|
94 |
> The package manager should treat flags listed in ``IUSE_RUNTIME`` |
95 |
> as regular USE flags, except for the following: |
96 |
> |
97 |
> 1. the state of the flags must be re-evaluated each time the package |
98 |
> dependency graph is considered, |
99 |
> 2. enabling or disabling any of the flags must not involve rebuilding |
100 |
> the package, |
101 |
> 3. the flags may be listed in the visual output in a distinct way |
102 |
> to inform the user that they affect runtime dependencies only. |
103 |
> |
104 |
> |
105 |
> Rationale |
106 |
> ========= |
107 |
> |
108 |
> The proposed solution tries to solve the issue of handling runtime |
109 |
> dependencies while reusing the existing infrastructure. Most |
110 |
> importantly, users will be able to reuse the existing tools |
111 |
> and configuration files to enable and disable optional runtime |
112 |
> and build-time dependencies alike. |
113 |
> |
114 |
> The remaining reused features include: |
115 |
> |
116 |
> - dependency syntax, |
117 |
|
118 |
If you invent new syntax, I'm going to be unhappy. KISS as it were. |
119 |
|
120 |
> - ability to use ``REQUIRED_USE``, USE dependencies, |
121 |
> - ability to describe flags in `metadata.xml`, |
122 |
> - global flag names (and descriptions). |
123 |
> |
124 |
> Alternative proposed solution involved creating additional ``SDEPEND`` |
125 |
> variable. That proposition had the following disadvantages: |
126 |
> |
127 |
> - being package-oriented rather than feature-oriented, |
128 |
|
129 |
No; use flags are our configuration space, and they turn on/off |
130 |
sections of the given pkgs graph. Your proposal relies on the same |
131 |
concept; bluntly, what you're proposing is just as 'package oriented'. |
132 |
|
133 |
Effectively, you can't dismiss SDEPEND/ODEPEND via changing the rules |
134 |
between your proposal and ODEPEND's proposal. Nice try though. :) |
135 |
|
136 |
|
137 |
> - lack of ability to express multiple packages required by a single |
138 |
> feature, |
139 |
|
140 |
Eh? SDEPEND="my_feature? ( pkg1 pkg 2 )" |
141 |
|
142 |
|
143 |
> - lack of ability to express cross-feature dependencies, |
144 |
|
145 |
Clarify. This is a wee bit too vague for responding to ;) |
146 |
|
147 |
|
148 |
|
149 |
> - lack of ability to describe features provided by enabled packages, |
150 |
|
151 |
metadata.xml's local use description already covers that; in your |
152 |
proposal above you lock in on use flags for the controlling of it |
153 |
(which, presumably you'll abuse to get descriptions of) yet claim it's |
154 |
not possible for ODEPEND (better name than SDEPEND :P). |
155 |
|
156 |
|
157 |
> - necessity of implementing a new user interface parts to control |
158 |
> the dependencies, |
159 |
|
160 |
Um... This is bullshit. Your proposal above is going to require a lot |
161 |
more implementation, documentation of how this all is supposed to |
162 |
work, and user ededucation for the weird scenarios where things don't |
163 |
behave as expected, or they don't understand why changing use flag X, |
164 |
results in the PM pulling in new packages (acting akin to -N), while |
165 |
changing flag Y doesn't, and only does so/rebuilds via -N. |
166 |
|
167 |
That's not one of those things we can easily summarize in a UI; not |
168 |
unless we want to extraordinarily verbose. |
169 |
|
170 |
|
171 |
> - lack of backwards compatibility. |
172 |
|
173 |
This is a bit of a stretch; to be clear, you're proposing that the |
174 |
depgraph changes in subtle/nasty ways on the fly under your scheme, |
175 |
and that a PM supporting IUSE_RUNTIME vs one that doesn't, won't find |
176 |
new and subtle ways to blow up the packages involved (specifically to |
177 |
expose differing behaviour). |
178 |
|
179 |
|
180 |
As ciaran said, I'd like to see an actual implementation if you're |
181 |
dead set on this route; ODEPEND/SDEPEND, not so much; it's |
182 |
straightforward. Your scheme basically requires the manager to |
183 |
continually recalculate large swaths of resolution subgraphs (every |
184 |
time), doesn't account for the fact that most PMs actually write a |
185 |
finalized form of the deps to the DB (for efficiency reasons, and |
186 |
since the USE state is locked), requires that optimization to be |
187 |
*reversed* basically everywhere. |
188 |
|
189 |
Mind you, I'm generally a bit of a harsh reviewer; I appreciate the |
190 |
notion/effort/emphasis, I just think bluntly that this is overly |
191 |
complex, and you're dismissing the saner/simpler solution w/out |
192 |
sufficiently strong reasons (especially in light of the complexity of |
193 |
the alternative, and consequences on PM behaviour/performance/user |
194 |
confusion). I could be wrong- feel free to blast back. |
195 |
|
196 |
~harring |