[lsb-discuss] lsb dynamic linker name for LSB 4.0

[Theodore Tso]

On Fri, Sep 12, 2008 at 12:57:47PM +0200, Dallman, John wrote:
> 
> I agree that not changing the soname makes it simpler this time 
> round. But if we find that it needs to be changed for LSB 5, and 
> then not again until LSB 8, or whatever, things start to get 
> confusing. That's why I'm arguing for maintaining the current 
> pattern unless there's a major positive reason to change it. 
> 

Sure, but think about it --- why would we ever need to change the
soname?  Traditionally, the only reason to change the soname is if
there is some fundamental breakage, such as changing a structure
layout, or changing the number of arguments in a function without
changing the function name or ELF symbol version.  This is the kind of
thing that we would never, ever allow in the LSB, so if we ever need
to do that kind of soname bump --- in the dynamic linker shared
library, no less! --- needing to change the number will be the
**least** of the confusion that will be involved, and the LSB will be
the smallest part of the chaos involved.

We've never *needed* to change the soname in the entire history of the
LSB (we bumped it out of superstition more than anything else), and
the ld-linux.so major version has never been bumped in the entire
*history* of glibc2 --- and glibc2 has been stablizing and the number
of changes in glibc in general has been slowing down.

The only thing that I could imagine requiring ld-linux.so changing a
major version (which would also drive ld-lsb.so major version) would
be a complete changeover from ELF to some other incompatible linking
format, which is pretty unlikely --- and if it did happen, it would be
such a major incompatible change, that would involve major breakages
all around the , debugging, and build chains, not to mention breaking
all sorts of internal LSB infrastructure --- the soname change will be
the ***least*** of the confusion.  I also believe this is so unlikely,
because of the absolute hell that it would drag the entire Linux
ecosystem through --- that it's really not worth planning changes
around this remotely unlikely possibility.

						- Ted