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 own peril. 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 additional software". > > 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 the dice. -- Aaron Gaudio icy_manipulator @ mindless.com http://www.rit.edu/~adg1653 -------------- "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.
