Developing LSB-certified applications (IBM developerWorks) [LWN.net]

Developing LSB-certified applications (IBM developerWorks)

Posted Nov 7, 2002 5:11 UTC (Thu) by airwin (guest, #6920) [Link]

These statements leaves me shaking my head in dismay:

"In general, applications have the potential to become LSB compliant if they can limit themselves to using only these 14 system libraries: libc, libdl, libm, libutil, libcrypt, libz, libpthread, libncurses, libX11, libXext, LibXt, libICE, libSM, and libGL."

"If an application cannot limit itself to the interfaces of the libraries listed above, then -- to minimize runtime errors -- the application must either bundle the non-specified library as part of the application, or it must statically link the library to the application."

That's an incredibly limited list of libraries. Such an approach might work well for Unix which is notorious for having only a small selection of native libraries, but Linux has lots of libraries. For example, I have almost 300 development libraries (/usr/lib/lib*.so) that I have installed on my Debian system right now, and I have not installed a complete list by any means. Also, it is very difficult to find a Linux package that doesn't link to libraries outside the list of the basic 14 above. And the "alternatives" of bundling or static linking any other required library makes for either very large packages or large and slow executables. So I cannot see any distribution going for this nonsensical requirement in the packages they distribute.

I think the LSB is a great idea, but this part of the implementation just seems way too rigid in my opinion. Wouldn't it just be a lot easier to use the soname mechanism to be sure you have the right version of the library for each application? All LSB would have to do, then is to maintain a list of the minimum version number that an LSB compliant distribution would have to support for each of the large number of Linux libraries. This minimum version number for each library is roughly consistent from one distribution to the next in any case right now. As libraries evolved over time, this minimum version number should be increased in such a way hat distributions wouldn't have to support more than say 2 major versions per library to be LSB compliant. This would force Linux packages to evolve with the changing libraries, but that is a good thing, IMO, and of course this is what happens now in any case. Also, it is some maintenance burden for LSB to keep track of minimum library versions for each Linux library as it naturally evolves, but that effort would be well worth it because it guarantees that if developers have at least that minimum version for the subset of Linux libraries that they use, that their application will work on all LSB-compliant distributions.

And of course that is the point of the LSB instead of enforcing some stupid library rules as quoted above.

Developing LSB-certified applications (IBM developerWorks)

Posted Nov 7, 2002 23:17 UTC (Thu) by dododge (subscriber, #2870) [Link]

That's an incredibly limited list of libraries.

Depends on your point of view. Some folks might even be surprised that things like Xlib and OpenGL are in the list. I see the latest draft has added PAM, too.

Such an approach might work well for Unix which is notorious for having only a small selection of native libraries

Yes, I can recall the days where if you wanted your Solaris application to be guaranteed to run on the end user's system, you had to static-link basically everything but libc and libdl :-)

Along the lines of working like Unix, from a quick skim of the draft LSB it appears that many of the command-line tools actually are defined to work just as in the Unix specification. Most of the fancy options and extensions that GNU has added are explicitly listed as deprecated for LSB purposes. From the DeveloperWorks article it's clear that this applies to the libraries as well, for example while LSB might guarantee that libc is there, it limits you to a subset of what glibc actually provides.

For example, I have almost 300 development libraries (/usr/lib/lib*.so) that I have installed on my Debian system right now, and I have not installed a complete list by any means. Also, it is very difficult to find a Linux package that doesn't link to libraries outside the list of the basic 14 above.

I agree, but where would you draw the line? It's going to be hard to find any desktop app these days that doesn't use gtk+ or Qt, if not full Gnome or KDE libs, so do you include those in the LSB requirements? If you include one of them you'd better expect to include both. And then you'll have the server folks freaking out because they don't see any point to putting all that desktop junk onto their machines just to ensure they can install some LSB-certified server packages.

The way I'm seeing it, the LSB is intended so that someone can put boxed software in a store and guarantee that it will install and run on the user's LSB-conforming machine. The user should not have to find, install, or otherwise upgrade anything on their machine; just put in the application CD and run the install command. It should install cleanly and not conflict with or break anything else on the system. Having a small set of libraries included in the LSB means that many types of applications are indeed going to end up having to bundle tons of libraries with their packages; but of course it also means that those application will at least be running against the expected versions of the libraries for support purposes. Adding a large set of libraries to the LSB makes the LSB a lot more complex, and makes the LSB a bad fit for some types of machines. This is after all the "base" standard, so it should probably apply pretty broadly.

So I cannot see any distribution going for this nonsensical requirement in the packages they distribute.

Considering the fee schedule required for LSB certification I don't really expect the non-commercial distributions to do the certification at all, and even the commercial distributions might not do it for individual packages. It really seems geared towards independent commercial boxed applications.

Aside: while I'm not exactly enthralled with their choice of RPM, I'm glad to see that they've documented the exact RPM and CPIO formats that LSB expects packages to use. Most of my bad feelings about RPM probably stem from the time when I had just gotten it ported to another OS, only to have RedHat change the format in an incompatible way and distribute the source for the new version in the new format.

Developing LSB-certified applications (IBM developerWorks)

Posted Nov 7, 2002 16:15 UTC (Thu) by airwin (guest, #6920) [Link]

No, I don't agree. I think the whole problem here is this aspect of the LSB is being pushed from the large company perspective rather than from a software packager's perspective. My view is the LSB is not doing its job if large packages such as KDE or GNOME (or small packages for that matter) still require individual binaries for each distribution. It is indeed a tough problem with many Linux libraries being used by such large packages, but nevertheless I think it can be solved using the soname mechanism and requesting that LSB-compliant distributions distribute up to two major versions of libraries. As it stands the LSB is absolutely useless for solving library compatibility problems for most Linux packagers for the reasons I indicated.