1 |
Hi, |
2 |
|
3 |
In some overlay ebuilds i'm maintaining for an OCaml software |
4 |
("Demexp", see http://tdegreni.free.fr/demexp if you're curious, |
5 |
but we don't really care for this discussion), i'm facing the |
6 |
following issue: |
7 |
- pkgA DEPENDs on pkgB, but does not technically RDEPENDs on it |
8 |
- pkgB have some USE flags to trigger optionnal use of some libs |
9 |
- pkgA will be linked to the libs used by pkgB |
10 |
So, the problem is to get accurate RDEPEND for pkgA: it should |
11 |
not include pkgB, but should take pkgB's USE flags, and thus the |
12 |
deps they introduce, into account. |
13 |
|
14 |
One possible (future) solution would be eradicator's GLEP about |
15 |
binary deps. RDEPEND would stay incomplete, but "soname.DEPEND" |
16 |
would keep track of what is missing, and thus it would in theory |
17 |
be possible to do a depclean without breaking pkgA. |
18 |
|
19 |
But before i realised that his proposal was actually covering this |
20 |
case, i've been thinking of a different approach which might be |
21 |
interesting too. |
22 |
|
23 |
|
24 |
{EX,IM}PORT_RDEPEND: |
25 |
==================== |
26 |
|
27 |
Example, with the above pkgA/pkgB case: |
28 |
|
29 |
=== pkgB.ebuild: === |
30 |
DEPEND="...whatever1... |
31 |
flagX? ( libX ) |
32 |
flagY? ( libY )" |
33 |
RDEPEND="...whatever2..." |
34 |
EXPORT_RDEPEND="flagX? ( libX ) |
35 |
flagY? ( libY )" |
36 |
|
37 |
=== pkgA.ebuild: === |
38 |
DEPEND="...whatever3... |
39 |
pkgB" |
40 |
RDEPEND="...whatever4..." |
41 |
IMPORT_RDEPEND="pkgB" |
42 |
|
43 |
The semantics of the above is pretty obvious: it would mean that |
44 |
pkgA's RDEPEND should be augmented with whatever pkgB has |
45 |
exported (depending on the USE flags pkgB is built with, could be |
46 |
either none, libX, libY, or both libX and libY). But pkgB itself |
47 |
would not become an rdep of pkgA. |
48 |
|
49 |
>From a syntactic pov, IMPORT_RDEPEND and EXPORT_RDEPEND are |
50 |
usual depstrings. |
51 |
|
52 |
>From a deps resolution algorithm pov, the (simplified) idea would |
53 |
be something like that: |
54 |
- pkgA's IMPORT_RDEPEND is evaluated into a list of cat/pkg-ver |
55 |
with the existing algorithm. Here, it becomes "pkgB-1.0" for |
56 |
instance. |
57 |
- we then need the reduced version of the EXPORT_RDEPEND of each |
58 |
of this packages: |
59 |
- if pkgB-1.0 is a new package to be compiled, then its |
60 |
EXPORT_RDEPEND is reduced for whatever USE flags it will |
61 |
be compiled with. |
62 |
- if pkgB-1.0 is already installed, then its already reduced |
63 |
EXPORT_RDEPEND is read from the vardb. |
64 |
- same if pkgB is a binary package to be installed, get it |
65 |
from its metadatas. |
66 |
- this reduced EXPORT_DEPENDs are added to pkgA RDEPEND, and |
67 |
resolution continue the normal way. |
68 |
|
69 |
|
70 |
Use cases: |
71 |
========== |
72 |
|
73 |
Sure, it would be exactly what i need in the case of my demexp |
74 |
ebuilds, but it could have many other uses too. In particular, |
75 |
it's an other way to solve the "binary deps are be more precise |
76 |
than compile deps" issue: |
77 |
|
78 |
- if "somelib-0.9.7" is incompatible with "somelib-0.9.8", but |
79 |
some package "foo/bar" can be compiled for any >=0.9.7 versions, |
80 |
we could have something like this: |
81 |
=== somelib-0.9.7.x.ebuild: === |
82 |
EXPORT_RDEPEND="=somelib-0.9.7*" |
83 |
=== somelib-0.9.8.y.ebuild: === |
84 |
EXPORT_RDEPEND="=somelib-0.9.8*" |
85 |
=== foo/bar.ebuild: === |
86 |
DEPEND=">=somelib-0.9.7" |
87 |
IMPORT_RDEPEND=">=somelib-0.9.7" |
88 |
And then a "foo/bar" binary package would have an accurate RDEPEND |
89 |
on "somelib", depending on what version it was compiled against. |
90 |
|
91 |
Note that this case would also be handled fine by eradicator's |
92 |
GLEP. At the contrary, the following would not i think (also |
93 |
last discussion here about this GLEP is a bit old, so maybe it |
94 |
has been extended since): |
95 |
|
96 |
- dev-python/somemodule depends on >=python-2.2, but once |
97 |
compiled/installed, it actually depends on the python version it |
98 |
was installed for. Solution: add an EXPORT_RDEPEND="=python-2.X*" |
99 |
to python-2.X ebuilds, and an IMPORT_RDEPEND=">=python-2.2" to |
100 |
the module ebuild. Same for perl modules, ocaml modules (which |
101 |
are even more picky on the versionning), etc. |
102 |
|
103 |
- programs/libs which do some dlopen("libfoo.so.X.Y") would not |
104 |
play nicely with automatic .so deps detection. At the contrary, |
105 |
the export/import mechanism is declarative and thus allow you to |
106 |
state whatever is needed to get accurate runtime deps, provided |
107 |
you've greped the code to find its dlopen calls. |
108 |
|
109 |
- in conjonction with the future "built with USE" depend atoms, |
110 |
it could be used to stick some flags in RDEPENDS. For instance, |
111 |
"foo/bar" depends on wxGTK, which can be built with or without |
112 |
unicode support. "foo/bar" really doesn't care about unicode, but |
113 |
once built against on or the other flavor of wxwidgets, it can run |
114 |
only with that flavor. Then we could imagine having: |
115 |
EXPORT_RDEPEND="unicode? ( x11-libs/wxGTK:unicode ) |
116 |
!unicode? ( x11-libs/wxGTK:!unicode )" |
117 |
(or whatever syntax it will be) in wxGTK.ebuild, and an import in |
118 |
foo/bar.ebuild. |
119 |
|
120 |
|
121 |
Open questions: |
122 |
=============== |
123 |
|
124 |
Well, there are many open questions left, like: |
125 |
- how could it be made transitive? (ie., how to re-export some |
126 |
imported deps) |
127 |
- should IMPORT_RDEPEND get a default value from (R)DEPEND? (in |
128 |
the cases i've thought about so far, each time an ebuild depends |
129 |
on something, it also wants its exported deps if any) |
130 |
- etc. |
131 |
But the most important one is: does it worth thinking more |
132 |
seriously about it or is this too complicated / useless / ...? |
133 |
Comments welcome. |
134 |
|
135 |
|
136 |
Thanks, |
137 |
|
138 |
-- |
139 |
TGL. |
140 |
|
141 |
-- |
142 |
gentoo-portage-dev@g.o mailing list |