[lsb-discuss] LSB apps on non-LSB distros (was Re: application certification questions)
robert.schweikert at abaqus.com
Sun Mar 4 21:52:30 PST 2007
I say the app installer does not need to be LSB compliant. It is the
ISVs responsibility to check for system requirements. Even if an app is
not LSB certified they will probably check at least the glibc version
and a few other things here and there. Every app has some requirements
and ISVs do not let users install their app any which way the user
pleases. If there is no checking a user might try to install and app
build on a newer distro on a really old distro like RedHat 5 (not a
typo, I do NOT mean RHEL 5).
Yes, I know this recreates the problem of testing on many distributions,
but it's just the installer and not the whole application. The other
approach of course is to have a java, python, or perl based installer.
On Sat, 2007-03-03 at 08:26 -0500, Ian Murdock wrote:
> On 2/28/07, Donya Shirzad <dshirzad at real.com> wrote:
> > 2) What are the options for backwards-compatibility? Right now our
> > installer for 3.1 depends on either the 3.1 linker (bin) or the 3.1
> > libraries (rpm) and fails on most of the systems out there. As 3.1
> > isn't wide spread yet, how can we get backwards-compatibility? Can we
> > Also, how is forward-compatibility taken care of? Will the OS be
> > shipping LSB 3.1 even after they are certified for 3.2 or will it break
> > our dependencies?
> This is another area where we need an immediate solution.
> On the one hand, the LSB is a great option for developers, since it allows
> them to create builds that run on any LSB certified/compliant
> distro, which is just about all of them
> HOWEVER, many of these distros do not enable LSB compliance by default.
> On many, the user has to take a specific action to enable it (say, yum
> install lsb or apt-get install lsb). This represents a barrier to
> adoption to the app vendors--it's one more step that a user has to
> perform (and potentially get wrong) before they can use their app.
> We're working on getting the distros to enable LSB compliance by default.
> However, we're not there yet, and we likely won't be till LSB 4.0. (We
> could try to push for it in LSB 3.2, but since nearly all of the LSB 3.x
> distros are currently in maintenance mode, such a big change
> would likely not be welcomed by the distros, and I wouldn't blame them.)
> So, in the meantime, we need a good solution to the problem of missing lsb
> dependencies and, in particular, binaries that link against ld-lsb.so not
> being able to run on non-compliant when they would PROBABLY work just fine.
> How about supplying an ld-lsb.so that simply calls into the standard
> linker, perhaps after printing a message along the lines of "Warning: This
> distribution is not LSB compliant. You may enable LSB compliance by doing
> XYZ. This application may not function properly until you do so." As with
> lsbinstall/xdg-utils, the ld-lsb.so shim could be part of the SDK,
> and we could make it easy for apps to bundle and install it as necessary.
> Note that this is just a slight variant of the old problem: "I still need
> to support RHEL 3.. How do I build an LSB 3 app that will work on RHEL 3?"
Robert Schweikert MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com) LINUX
Phone : 401-276-7190
FAX : 401-276-4408
More information about the lsb-discuss