Re: New control field proposal which could help on gcc3.2 transition
On Thu, 12 Sep 2002, Manuel Estrada Sainz wrote:
> Debian packages have been repeatedly bitten by the fact that a package
> breaks its ABI as it evolves, which means that dependencies like:
> 'foo (>= X.X-X)' ends up not been quite enough; Something like 'foo (>= X.X-X),
> foo (<< Y.Y-Y)' would be more efective, but Y.Y-Y is usualy unknown when
> writing those dependencies.
[snip]
Well, I wish it was so simple to solve..
First off, your proposal couldn't have helped with the libc5->libc6
transition. That had the requirement that both libc5 and libc6 versions of
the library co-exist on the same system. The 'g' addition was mandatory.
Technically, all of our transitions should have this property for a smooth
upgrade path and maximum inter-distribution compatibility - but in
practice it probably isn't too important for some packages..
But, fundamentally, what you are proposing boils down to putting an ABI
field in the control header that has exactly the same semantics as the
soname, but is enforced by dpkg not the linker.
The problem with that is that our libraries will have the same soname but
a different ABI than libraries from other distributions. ie if we
use your proposal, recompile qt2 and all it's reverse depends then we will
no longer be able to run KDE applications from say Mandrake. They will
load but segfault or get wierd runtime linking errors.
A real solution to this needs to have upstream involved. Upstream has to
encode these sorts of things in the soname, or specify which G++
ABI and, and which versions of other libraries they expect for a given
soname.
Now, that said, your idea for a solution does have good properties for
low-use packages. But the same effect can be acheived with versioned
provides, and some upfront thought..
Jason
Reply to: