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
On Thu, 2006-09-21 at 09:52 -0400, Mike Frysinger wrote:
> On Thursday 21 September 2006 07:59, Brian Harring wrote: > > Why have the explicit var? Because 0.9.7a through 0.9.7c may all be > > compatible, but 0.9.7d isn't. If you force an automatic algo that > > tries to (effectively) guess, you get a lot of rebuilds through a,b,c, > > end result being folks likely update less because it becomes a bigger > > pain in the ass. > > if it isnt compatible then it shouldnt have the same SONAME, simple as > that ... that is after all the point of encoding the ABI version number into > the SONAME > > forcing devs to maintain a manual var which is basically duplicating the > SONAME smells like maintenance nightmare
There are various kinds of ABI. Certainly for C libs the SONAME is probably the most common. If we go for some kind of ABI reverse deps feature I would beg for something a little more general - though certainly with SONAME as a common case. Other languages have similar problems. For example Python has incompatible ABIs for each major release 2.2, 2.3 etc. They have a similar solution to the revdep-rebuild: python-updater. As lead of the Haskell team my interest in this is that our primary Haskell compiler GHC has ABI incompatibility between versions too. We've made a ghc-updater similar in style to the python one but this is clearly an unsatisfactory situation. It's more acute for us as even minor revisions are ABI-incompatible. So for it's something like: # for C: ABI=${SONAME} # for python ABI=${PY_PV} # for haskell: ABI=${GHC_PV} paludis has something going in this direction but I don't think it'd quite solve the python/ghc abi issue. It was aimed more at cases like mips with it's multiple abis. If we do go in this direction it'd be great to be able to slot on the ABI and still have dependencies resolved correctly. For example imagine having parallel python-2.3 and 2.4 installations with some libs installed for both. Crucially, deps need to be resolved to the version of a lib with the right ABI. debian solves this problem in an ad-hoc way by tacking extra components into the package name: pyfoo-py22.deb which deps on pybar-py22.deb pyfoo-py23.deb which deps on pybar-py23.deb so all can be installed at once and deps are resolved within the right ABI. Now this is obviously not in the Gentoo tradition. We much prefer cleaner solutions like SLOTing. I would love to see this extended to allow us to SLOT on the abi and then correctly resolve based on that abi. If we just SLOTed at the moment we'd get the sitation where dev-python/bar built for py 2.2 would be considered ok to satisfy a dependency of dev-python/foo that is being built for py 2.3. We want some kind of extra component to be able to resolve on: dev-python/foo-1.0.ebuild: SLOT="${PV}-${PY_PV}" ABI="${PY_PV}" DEPEND="dev-python/bar @ ${PY_PV}" Actually for Haskell the situation is even more fun; we have multiple haskell implementations, so we would like to install a lib and SLOT upon and correctly resolve deps for multiple haskell compilers. Fun stuff. :-) If portage people are interested in moving in this direction we have an experimental emerge-compatible mini dep-resolver which might be useful to prototype an extended ABI/SLOTing system. Duncan Coutts -- gentoo-dev@g.o mailing list


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>