Gentoo Archives: gentoo-dev

From: Duncan Coutts <dcoutts@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC about another *DEPEND variable
Date: Thu, 21 Sep 2006 14:59:58
Message-Id: 1158850564.16173.97.camel@localhost
In Reply to: Re: [gentoo-dev] RFC about another *DEPEND variable by Mike Frysinger
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

Replies

Subject Author
Re: [gentoo-dev] RFC about another *DEPEND variable Simon Stelling <blubb@g.o>
Re: [gentoo-dev] RFC about another *DEPEND variable Mike Frysinger <vapier@g.o>