[lsb-discuss] Program interpreter and non-LSB compatibility

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Jul 26 16:54:30 PDT 2006


>"Your app should have a dependency on the lsb keystone package..."
>
>Should or must? Is it possible to have an LSB-certified 
>application which does not require the lsb keystone package?

a conforming application /must/ depend on "lsb", but there's
no requirement that the package manager provide "lsb" comes
from a keystone package that depends on everything else that
is needed for LSB conformance - that's just a convention that
has evolved.

>I'm still not really sold on the program interpreter issue. I 
>have yet to hear about a customer who had problems running
>our software on any distribution because of a difference in
>program interpreter versions. When does this happen? I find
>it far more likely that someone will have problems because 
>they don't have LSB than that they would have problems 
>with an actual incompatible ld-linux.so.2. 

That's not the purpose.  Instead, the purpose is to provide
a "hook" such that if something different has to happen to
run an LSB program, it can be done.  If no hook is needed,
nothing more than a symbolic link to the real dynamic linker
is needed.  So a specific example is Debian: the Sarge
libc.so.6 is slightly older than what is needed for LSB
conformance for a particular version.  There is no way to
uplift the library, that's a major-release type issue, so
instead an alternate copy is provided only for LSB conformance,
and the LSB dynamic linker pulls that one in at runtime,
while all other applications, which won't have ld-lsb as
the dynamic linker, get the normal one.

>So our choices are:
>1. Officially support LSB and make customers on non-LSB 
>distributions jump through hoops to run our software

it's smallish hoop, but it is a hoop: you would need to
provide a mini-package that provides the "lsb" dependency
and also sets up the symlink, but while this works and
is very simple (we have such a package internally which
we use to let use play with systems before the distros
have provided full conformance for a new release), it's
also a bit deceptive: the presence of the "lsb" provide
is supposed to imply that this is a conforming system,
and if it really isn't, the wrong impression might be
gained, perhaps by someone else's LSB package.

>2. Unofficially support LSB by trying to follow most of the 
>standards, but don't require the LSB package and don't 
>change our program interpreter, risking the very rare case
>in which someone actually would have a problem with this.

This model will probably work; as I said it's not about 
the ld.so being incompatible.  




More information about the lsb-discuss mailing list