1 |
On Thu, 2006-09-21 at 09:52 -0400, Mike Frysinger wrote: |
2 |
> On Thursday 21 September 2006 07:59, Brian Harring wrote: |
3 |
> > Why have the explicit var? Because 0.9.7a through 0.9.7c may all be |
4 |
> > compatible, but 0.9.7d isn't. If you force an automatic algo that |
5 |
> > tries to (effectively) guess, you get a lot of rebuilds through a,b,c, |
6 |
> > end result being folks likely update less because it becomes a bigger |
7 |
> > pain in the ass. |
8 |
> |
9 |
> if it isnt compatible then it shouldnt have the same SONAME, simple as |
10 |
> that ... that is after all the point of encoding the ABI version number into |
11 |
> the SONAME |
12 |
> |
13 |
> forcing devs to maintain a manual var which is basically duplicating the |
14 |
> SONAME smells like maintenance nightmare |
15 |
|
16 |
There are various kinds of ABI. Certainly for C libs the SONAME is |
17 |
probably the most common. If we go for some kind of ABI reverse deps |
18 |
feature I would beg for something a little more general - though |
19 |
certainly with SONAME as a common case. |
20 |
|
21 |
Other languages have similar problems. For example Python has |
22 |
incompatible ABIs for each major release 2.2, 2.3 etc. They have a |
23 |
similar solution to the revdep-rebuild: python-updater. |
24 |
|
25 |
As lead of the Haskell team my interest in this is that our primary |
26 |
Haskell compiler GHC has ABI incompatibility between versions too. We've |
27 |
made a ghc-updater similar in style to the python one but this is |
28 |
clearly an unsatisfactory situation. It's more acute for us as even |
29 |
minor revisions are ABI-incompatible. |
30 |
|
31 |
So for it's something like: |
32 |
# for C: |
33 |
ABI=${SONAME} |
34 |
|
35 |
# for python |
36 |
ABI=${PY_PV} |
37 |
|
38 |
# for haskell: |
39 |
ABI=${GHC_PV} |
40 |
|
41 |
paludis has something going in this direction but I don't think it'd |
42 |
quite solve the python/ghc abi issue. It was aimed more at cases like |
43 |
mips with it's multiple abis. |
44 |
|
45 |
If we do go in this direction it'd be great to be able to slot on the |
46 |
ABI and still have dependencies resolved correctly. For example imagine |
47 |
having parallel python-2.3 and 2.4 installations with some libs |
48 |
installed for both. Crucially, deps need to be resolved to the version |
49 |
of a lib with the right ABI. |
50 |
|
51 |
debian solves this problem in an ad-hoc way by tacking extra components |
52 |
into the package name: |
53 |
|
54 |
pyfoo-py22.deb which deps on pybar-py22.deb |
55 |
pyfoo-py23.deb which deps on pybar-py23.deb |
56 |
|
57 |
so all can be installed at once and deps are resolved within the right |
58 |
ABI. Now this is obviously not in the Gentoo tradition. We much prefer |
59 |
cleaner solutions like SLOTing. I would love to see this extended to |
60 |
allow us to SLOT on the abi and then correctly resolve based on that |
61 |
abi. |
62 |
|
63 |
If we just SLOTed at the moment we'd get the sitation where |
64 |
dev-python/bar built for py 2.2 would be considered ok to satisfy a |
65 |
dependency of dev-python/foo that is being built for py 2.3. |
66 |
|
67 |
We want some kind of extra component to be able to resolve on: |
68 |
|
69 |
dev-python/foo-1.0.ebuild: |
70 |
|
71 |
SLOT="${PV}-${PY_PV}" |
72 |
ABI="${PY_PV}" |
73 |
DEPEND="dev-python/bar @ ${PY_PV}" |
74 |
|
75 |
Actually for Haskell the situation is even more fun; we have multiple |
76 |
haskell implementations, so we would like to install a lib and SLOT upon |
77 |
and correctly resolve deps for multiple haskell compilers. |
78 |
|
79 |
Fun stuff. :-) |
80 |
|
81 |
If portage people are interested in moving in this direction we have an |
82 |
experimental emerge-compatible mini dep-resolver which might be useful |
83 |
to prototype an extended ABI/SLOTing system. |
84 |
|
85 |
Duncan Coutts |
86 |
|
87 |
-- |
88 |
gentoo-dev@g.o mailing list |