Re: X and LSB
And lo, the chronicles report that Robert W. Current spake thusly unto the masses:
> Outline a structure for KDE and Gnome to build on and spec with is an
> issue Alan was discussing. My suggestion is that X be laid out as a
> sample implementation of how something can easily fit onto the base, and
> how the LSB "base" itself works to make that easier and more standard
> across the distributions.
> And, some of the work on that has already been done ;-) I'm just saying
> move X onto the the top of a base layer. This will provide a model for
> checking a standard dependency (Is X there and functional? LSB says it
> should be in location X, and tests for it with the X test suite, so if
> LSB says X is there, then I can count on it being there).
The problem is this: there are already ways for vendors (by which I mean
not only commercial vendors, but any third-party software distributor)
can list the dependancies of their software and package it in such a way
that those dependancies are checked before installation. Both RPM and
DEB and surely lesser-known package formats support this.
Similarly, one can write a package which requires glibc2.1 and won't
settle for less. The problem is, as such a vendor (rhetorically), I want to
make sure that my product will reach the "common" Linux market. It is not
sufficient for me to say, "My product depends on glibc2.1, so go and get it".
I want to move where the majority of my market is, so the question for me
becomes "I want to have a product that will 'just work' on as many Linux
boxes as possible (of course, within the constraints demanded by the nature
of the product), so what target would be the best one for my product to
depend on? glibc2.0 or glibc2.1? etc". When I don't know the answer I either
am forced to guess, or forced to produce two or more versions of the product,
each tailored to the appropriate system. I shouldn't have to worry about that.
LSB can define a standard that would say, for instance, that glibc2.0 will
be available on any LSB-compliant system, so depend on glibc2.1 at your
These issues do not stop at the C Standard Library. For graphical software,
vendors want to know what toolkit they can count on people having, what
version of the libraries they will have, what capabilities they can count
on their GUI having. These are important issues. Are they important to all
users? Of course not. Then again, what version of libc++ is installed
in users' systems is not important to everyone either.
> The issue of moving X out of "the base" is different. X isn't a basic
> component of Linux, it is an incredibly useful piece of software that
> can be used on a Linux system. So, it should be treated as such.
It is more than incredibly useful. Look, I can have xmms and its associated
libraries installed in my system and very few other application developers
would give a hoot. But they sure as hell want to know what version of X
I'm running, and what toolkit(s) I'll have installed, because without that
knowledge, their applications may not work on my machine. The same is true
of xmms, but there simply is not the application market out there for xmms-
based applications. X is more than useful, it is essential if you are talking
about real-world graphical applications for Linux. Is every Linux box owner
interested in graphical applications for Linux? Nope. But there sure is
quite alot of them, and there sure are alot of people who want to write
software to them. These people don't want to have to worry about making
multiple packages for each combination of X version/toolkit and version that
may exist on any given user's machine. LSB should simplify that for them by
saying "hey, you can use whatever you want, but if you use XXX, you are
guaranteed that any LSB-compliant system will be able to run it without
> Many people want an X API there. I don't deny that. I never have. I
> am saying that an X API isn't a "base" issue, it's a standardization
> issue. But, in terms of how the fundamental structure of a system
> should be built, X sits on a layer above the OS. That makes a strong
> case for outlining the structure of the standard to reflect X is a layer
> above the OS itself.
X is an optional part of the OS. I would not even say it is not part of the
OS anymore. It is not part of the kernel (even this distinction is becoming
blurred with DRI, but anyways), but it certainly is part of the OS. The fact
that its operation is not required to run Linux doesn't make it not part
of a Linux OS. As I stated before, what is and is not part of the OS should
be up to the distribution in question. LSB is not out to define "what is
Linux" it is out to define the common set of libraries and utilities and
what not that the different flavors of Linux will agree upon. If a branch
of such libraries show themselves to be important within the context of the
LSB's goal for software compatibility, then it should be considered in the
standard. There should probably be layers to the standard which define
optional parts (there are lots of people who don't need make, for instance,
because they don't do development on that particular box), and you make
a good argument for that. But to leave it out of the specifications
altogether is a mistake, IMO.
> By no means would I suggest X not be addressed in some way. The goal of
> the LSB is to address how software can have a logical structure to sit
> on the OS, and how using this logical structure, it will be a little
> easier for others to run their software on the OS.
Not really. We already have FHS and one can debate how well it is adhered
to, but it is out there. We already have dependancy checking in all the
major package formats. The question is, how can application developers avoid
having to support multiple OS configurations (libc5/glibc2.0/glibc2.1, for
example), and instead concentrate on producing better software? Compatibility.
If there is a large market of X-based applications, it is not enough to
define how to see what version of X is installed, it is necessary to say
what version of X *will* be installed (or a backwards-compatible version
thereof) in a standards-compliant system. Bleeding-edge folks will have
to wait for the standard to catch up with them and in the meantime, roll
icy_manipulator @ mindless.com
"The fool finds ignorance all around him. The wise man finds ignorance within."
Use of any of my email addresses is subject to the terms found at
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.