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@gentoo.org mailing list
