LDPS 1.0 lays an egg LinuxWorld.com 10/20/00 Nicholas Petreley, LinuxWorld.com After three years of hibernation, LSB has finally produced a deliverable. It is called the Linux Development Platform Specification, or LDPS 1.0. According to the LDPS 1.0 documentation, "This specification is designed so that programs developed on a conforming platform are expected to be portable to all generally available Linux distributions as of October 7, 2000."

Advertisement On this topic Data Management Strategies. Sign up Now! New Strategies to Effective Business Continuity Go for broke on open source Java JFS for Linux

Does it meet that goal? Not at all. Although LDPS 1.0 falls short in nearly every aspect, I can illustrate the problem through one example: ncurses. The ncurses library provides programmers a common way to write sophisticated character-mode applications. In order to be LDPS 1.0 compliant, a distribution must include either ncurses version 4.2 or ncurses version 5.0.

The specification states that applications compiled for one version should run without modifications on the other, with some exceptions. Then the specification goes on to list some of those exceptions.

By admitting the exceptions, LDPS 1.0 leaves developers unable to pick one library version and use it confidently. You have to make sure you haven't used some feature that would cause incompatibilities, whereas you should just be able to compile your application for one library version and expect it to run properly. Since the LDPS 1.0 document does not attempt to detail all of the possible incompatibilities, you're basically on your own.

LinuxWorld.com links LinuxWorld.com home Best of LinuxWorld.com The Legacy Files The Penguin Brief Version Control Linux links Linux forums

One need go no further to conclude that LDPS 1.0 is meaningless with regard to ncurses. But it gets worse. The LDPS document indicates that the following distributions, among others, are LDPS 1.0 compliant: Caldera 2.4, Debian 2.2, Mandrake 7.0, and Red Hat 6.2.

Caldera 2.4 includes ncurses 4.2 and puts the library in the directory /lib. Debian 2.2 seems to have both ncurses 4.2 and ncurses 5.0 and also puts the libraries in the /lib directory. I don't have a copy of Mandrake 7.0 to check, but Mandrake 7.1 includes several versions of ncurses, including both 4.2 and 5.0. All the libraries go in /usr/lib. Red Hat 6.2 includes a package that is labeled as ncurses 5.0, but if you examine the contents of the package, you'll only find libraries for ncurses 4.0. As far as I can tell, Red Hat does not even create symbolic links to give the impression that ncurses 5.0 libraries are installed. This could be a packaging error that may be fixed by an update to 6.2. The 4.0 libraries are installed in the directory /usr/lib.

If your application expects to find the library named libncurses.so.4.2, then it will only run on Caldera and Debian. If it expects to find libncurses.so.4, it will only run on Debian or Mandrake. If it expects to find libncurses.so.4.0, then it will run on Red Hat or Mandrake. If it expects to find libncurses.so.5, then it will only run on Debian or Mandrake.

It is not difficult to modify the above distributions to accommodate all the variations on ncurses 4.2 and 5.0, but the distributions will have those incompatibilities out of the box. LDPS does nothing to encourage distributions to take the simple steps necessary to fix the problem. LSB simply kowtows to existing distributions with its specification when it should push distributions to become more compatible. As I have said before, LSB needs more guts than that.

As for ncurses, here is one way to effectively solve the incompatibility problem. Require all distributions to produce updates that install both ncurses 4.2 and 5.0, and create the symbolic links necessary to provide every possible library name an application may expect to find. LSB should award the recognition of compliance only to those distributions willing to produce the updates. Then -- and only then -- could you use LDPS as a reliable guideline for compatibility.

Granted, developers must expect people to apply updates for their applications to work. But that is no different than when an application requires service pack 4 or later in order to run on Windows NT 4.0. Surely if Linux expects to compete with Windows NT, it can work within the same framework as Windows NT.

One of the biggest problems with LDPS is the word or. A distribution can be LDPS 1.0 compliant by including either ncurses 4.2 or ncurses 5.0. Since it is so simple to provide both, why did LSB allow distributions to provide either? Some of the currently available distributions include only one or the other. LDPS should specify that these distributions must include both or be declared noncompliant with LDPS 1.0. LSB should require such distributions to change before recognizing them as compliant.

Does this mean that LDPS 1.0 is the result of pressure from distributions to produce a specification that is compliant with their products instead of the reverse, as it should be? I do not believe so.

I can only speak for one distribution on the topic of LSB. When Caldera Systems hired me to work with LSB, I was never given even the hint that I should encourage specifications to match existing distributions from Caldera. In fact, to its credit, Caldera has been remarkably hands-off in my employment, and when I have suggested changes to its Linux product, they have been received well. The bottom line is that there is no evidence that Caldera is influencing the LDPS 1.0 specification for its own benefit.

In addition, one rarely finds representatives from various other distributions arguing that their distribution should constitute the standard. And when they do, they are often overridden.

So while it is tempting to blame the distributions for the woefully inadequate LDPS 1.0, I see no evidence of effective meddling by the distributions in order to make the specification conform to their products. I am left to assume that the problems with LDPS 1.0 are internal to LSB. If LSB is kowtowing to distributions as I suspect, it is doing so of its own volition.

Nick Petreley is the founding editor of VarLinux.org (www.varlinux.org). Reach him at nicholas@petreley.com.