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

Theodore Tso tytso at MIT.EDU
Fri Sep 12 10:37:48 PDT 2008


Mats,

	Thanks for a very good summary about the compatibility issues
in question.  The one thing I would add is that nearly of your exaples
are about when we would actually need to use the ld-lsb "escape hatch"
--- for example, when Debian started going years without stable
releases and we wanted to go to newer libraries for LSB 3.0.

	But it doesn't raise the question of when we might need to use
*different* sonames for ld-lsb.  For example, when would it ever
happen that we would need to distinguish between a application meant
for LSB 5.x and LSB 4.x?  Well, the only time we would need ld-lsb !=
to ld-linux is if the system shared libraries can't support the level
needed for the LSB libraries.  For example, suppose Debian's release
team self-distructs, with several more people either resigning or
refusing to help out with the Lenny release, claiming lack of
motivation, and seven years goes by without Lenny getting released.
Granted, an unlikely scenario, but not entirely out of the question,
given some of the drama that Debian community seems to be so good at
generating.  :-)

	OK, suppose by then we release LSB 6.x --- and by then, we'd
probably probably need the /lib/ld-lsb != /lib/ld-linux escape hatch
for Debian.  But would we only need ld-lsb soname to be different?
Only if there was something so majorly different that not only would
it not be enough for ld-lsb force using a different "universe" of
shared libraries, but that we needed a *different* universe of
libraries for LSB 4.x vs LSB 5.x or LSB 6.x.  That is, we would only
need it if we deliberately create a specification where we had broken
the LSB backward compatibility promise --- that is, where an
application compiled for LSB 4.0 doesn't work on a LSB 4.1 or LSB 5.0
certified distribution.  Whether we would do something quite this
self-destructive and something that would cause ***massive*** pain to
ISV's is completely under our control ---- and it's hard to imagine
any situation where we would deliberately elect to screw over ISV's
like this.

	And even if we at some future point thought we needed to do
something like this, we could just as easily put a ELF comment, and
have the ld-lsb dynamic loader read out the ELF comment, and change
its behavior accordingly.

> All this really is is an insurance policy.  There's a cost to obtaining
> the insurance, which you want to balance against the risks you're
> protecting against.   We've heard some enumeration of both costs and
> potential risks in replies in this thread... hopefully the discussion
> will settle down on whether we want to take out the insurance or not.

	In the final analysis, that's absolutely correct.  So the
question is quantifying the risks, and asking ourselves how to keep
the costs as low as possible.

	From a cost benefit standpoint, having some way of
intercepting the dynamic loader so we can substitute the distribution
shared libraries for an LSB-specific set of libraries --- for example
when distribution can not or will not update its libraries to a set
compatible with the latest version of the LSB --- seems to be useful;
after all, it's been used once, and Debian is still trying to shake
the reputation that the Debian Stable release == Debian Obsolete.

	But in terms of keeping the costs as low as possible, changing
the soname doesn't actually buy us anything.  Certainly, it's clear
that we don't need it to distinguish between LSB 3.0 and LSB 4.0.  And
its usefulness is very limited, given that we can't use it to tell the
difference between LSB 4.0 and 4.1 (even assuming we wanted to make
some horrible backward incompatible change and break the promise we've
made to ISV's about, well, not doing that).  If for some reason it's
useful for a binary sans documentation or packaging, the real right
answer there is to use an ELF comment --- especially given that with
the best-efforts dynamic linking feature, the name ld-linux.so name
won't even be in DT_NEEDED at all.

	Regards,

							- Ted


More information about the lsb-discuss mailing list