Before I reply to specific things here, let me restate the mission statement of the LSB, as found at http://www.linuxbase.org:
"The goal of the Linux Standard Base (LSB) is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant Linux system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux." Unless you disagree with this fundamental mission statement, what the LSB "should" and "should not" do should always fall back on this. And lo, the chronicles report that Robert W. Current, Ph.D. spake thusly unto the masses: > > Second, any issue of "software packaging" should NOT be standardized by > the LSB. Part of compatibility means binary compatibility. In fact, the libc5/glibc fiasco (which is still going on today in some forms) was, as I understand it, one of the motivating forces for the LSB. First, we must recognize that "enabling software applications to run on any compliant Linux system" means not only open source but proprietary, commercial applications. Users and administrators can't always get the source and recompile. On the library level, this means that the LSB must provide a standard set of the core libraries which application vendors can link to. We must also recognize that (binary, and to a lesser extent, source-releases) software comes in packages. Whether the format is cpio, tar.gz, deb, rpm, etc. there will be packages, and vendors will want to know what package format to use to reach the widest market, but also which will integrate with what that market has (that is, not just providing tarballs and leaving it to the sysadmin to figure out what it actually installed and the dependancies, etc). The current system is only workable because there is a de facto standard: rpm. But still you often find software packages provided in deb, rpm and tar.gz. Why should vendors and developers have to worry about packaging up their software in every conceivable package format? Many give up and let third parties do it, but this is not a good solution either because it makes such packages less accessible to the people who want them and don't necessarily want to compile their own. The LSB has recognized this situation. I'm sorry I'm unable to keep up with all the spec development for LSB so rather than defend what's in there, I'll say that what should be in there is not that an LSB-compliant system has to use XXX package manager, but that it has to be able to somehow handle XXX-format packages. LSB has chosen the de facto standard and made XXX=rpm. > > Third, although I believe .tgz, .deb, .rpm, and the like are something > the LSB shouldn't endorse, I do feel that how these packaging systems > interact with what is "a LSB Compliant System" must be addressed. This > can NOT be avoided. THINGS MUST CHANGE! > > Packaging systems must be free to develop on thier own, and do thier own > thing. BUT, most likely, all of them will have to be "adjusted" so that > they fit within the scheme of what it is that the LSB is trying to > address. Perhaps, but this should be kept to a minimum. LSB is not a standards think-tank trying to guide the course of Linux. They are merely trying to document the de facto standards, only making directional decisions when no de facto standard is obvious. At least, this is how I understood it. Top down standards rarely work, and even more rarely are adhered to. LSB should not be in the business of such work, it should rather be collating what's already out there, keeping in mind that some contraversial decisions might have to be made, but should be kept to a minimum. > > And, finally.... IT'S BROKE! Yes, IT'S BROKE! We MUST FIX IT. No "if > it ain't broke, don't fix it" stuff applies. There is an absolute need > to change some of the fundumental underlying structure of what "Linux" > is... "Linux" must be DEFINED! Why? What's broke, specifically? The chief problem the LSB is seeking to redress is that different users with different vendors' versions of Linux are having a hard time sharing software. Software vendors are having a hard time choosing a single target for their products. Wether a package installs into /usr or /usr/local, IMO, is not a critical issue and furthermore does not affect the mission of the LSB, which is to increase compatibility. If a package is "non-standard", then how other packages depend on it for compatibility is not an issue LSB must concern itself with. Thus, if I install netscape into /usr/bin instead of /usr/local/bin, the only things that this will affect is packages which depend on netscape and since netscape is not a base package, the LSB cannot be expected to deal with that. > > As a result, "Linux" should be defined as "An Operating System" and the > LSB should be working to define "The OS" and not "Linux Software." The > blurred line of where the OS ends, and where the software starts is the > fundumental thing that has caused a complete lack of progress in > defining what the LSB is and does since it's very beginning. Where exactly is this line? Technically, it would be at the kernel. Linux is the kernel, and all else is the software. Having the LSB issue a kernel standardization would not only be futile, it would help little in terms of compatibility. A modern "Operating System" is usually meant to mean more than a kernel though. It means the kernel plus the core set of tools which the users and administrators will use to get their work done. No one suggests that telnet is not part of the Unix operating system. Or Bourne shell. Or sed. Etc. To that extent, you are right that the LSB should take to standardizing these core utilities, their placement and their usage, much as UNIX98 does for Unix. LSB should not standardize netscape, including where it installs to, except to say "here is the FHS, try to keep true to it". If a non-standard package does not keep true to the FHS, then that's a problem to take up with the vendor. If something installs into /usr instead of /usr/local and you don't like it, then talk to the vendor and plead your case. What is LSB going to be able to do about it? > > It's time to draw the line in the sand. It's time to lay down "what the > OS is" and "where the software sits on the OS." That is the struggle. > That must be done. Once this issue is addressed, and finally laid to > rest, THEN, and ONLY THEN, will we be able to move forward onto the new > frontier. That is, IMO, what the LSB is doing. Your chief complaint seems to be that you don't include some of the things that LSB considers the OS. Let's not throw out the entire spec because it differs on your opinion of which software belongs in that definition, though. Deal with such differences individually. > > With my strong believes, I have layed out my very first Linux Standard > Base Request for Comment. Please, take the time to read through this > first rough draft, and, do comment (that's what RFC's are for after > all). > > I'm sick of watching Linux and the LSB flounder, and I am going to start > pushing this issue. I'm not going to go away until these issues are > addressed, nor are the problems. It's for what I believe is the good of > Linux and the Linux Community as a whole that drives me to write this. > > > ================================== > R. Current's LSB RFC (Rough Draft). > > Scope: > What LSB should be doing: > Defining what the "Linux OS" is, where it starts, and more importantly, > where it ends and "Linux software" begins. > Defining what LSB Compliant means. > Defining what standards LSB compliant systems conform to (POSIX, SYS V, > FHS) > > What LSB should not do: > Define a Linux software packaging "standard." > Rewriting the POSIX standards. > Rewriting the FHS standards. These issues are discussed in broad strokes in the mission statement. Are you suggesting that the LSB should change their mission statement, which does not limit itself to what you are proposing above. Perhaps what you want from the LSB is not quite the same thing that the LSB is seeking to provide. The chief goal of the LSB is compatibility; getting the same software to run regardless of system vendor. Within that context, some of the "things LSB should be doing" above fall within scope, but so do some of the "things LSB should no do" above (packaging standards, specifically). > > > Problems: > Someone will always claim "it's not enough" > Someone will always claim "it's asking the distributions too much in > order to conform" > > Solution: > Throw out the "opinions" of how much or how little is being "asked" and > get down to the simple facts of what is "correct" for a Linux system, > and what is "incorrect" (based in solid facts). Being ideologically correct and having a standard that people adapt are not necessarily one and the same. LSB must take into account the politics of the market as well as the installed base. Think if LSB came out with a spec and companies like Red Hat and SuSe ignored it. It could be the greatest spec in the world, but wouldn't amount to a hill of beans because the majority of the market would ignore it. Remember XTI? Neither do I. > > Issue 1) > POSIX > Linux systems that are LSB compliant will pass a standard battery of > tests, including POSIX testing. Agreed. LSB should require POSIX compatibility, except under some situations (where the common usage of a GNU utility, for example, differs from the "posixly-correct" syntax). In such circumstances, there should be a POSIX mode of usage (and I believe there is, either via command-line option or environment settings, for most if not all such GNU utilities). > > Issue 2) > Software, where do we draw the line? > If it's "required" for POSIX compliance, it's "Standard." > If it's undeniably "standard issue", it's "standard." Here's the problem. What does "undeniably standard issue" mean? It will mean different things to different people. For instance, you feel that X11 is not "undeniably standard issue" because a server can run without X11. True, but not including some mention of X11 in LSB leaves out an entire class of applications whose vendors will want to know what to expect from an X-enabled system (e.g. what toolkit to use?) and that is to the detriment of compatibility, the chief mission of the LSB. > > What's not standard? > httpd, ftpd, outside shells (csh and bash maybe standard, zsh, esh, etc, > are not), anything that is not essential in passing the "LSB Compliant > Test Suite" is considered "software" and therefore not "standard to a > Linux BASE system" This is a recursive definition. The LSB-Compliant Test Suite will test everything that's standard to an LSB-Compliant system. The Test Suite is developed with the standards in mind, not the other way around. That being said, things like X would be optional. The LSB would not be saying "you must have X11", it would be saying something like "if you have X11, then GTK X.X must be available". > > What if "non-standard" software is very common? Tough shit, that's > life, it's not part of what it means to be a "Linux Standard Base" > system. But ignoring very common software is to the detriment of the mission, which I reiterate is compatibility. If a whole class of software exists and needs guidance to be made compatible across systems, then that is a job for the LSB. Whether to use GTK or Motif or Qt and expect other people to have said libraries is a big issue, and not one to be cast off lightly. > > Implications: > According to FHS and "good Linux Housekeeping", non-standard software > should NOT, and I repeat, NOT be in /usr/bin Oh? I looked at the FHS and don't see this anywhere. The FHS makes no distinction betweek "standard" and "non-standard" software because it is not standardizing software and so such a discussion in the context of the FHS is irrelevant. This is what the FHS 2.0 says about /usr and /usr/local: "4 The /usr Hierarchy /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various hosts running FHS-compliant and should not be written to. Any information that is host-specific or varies with time is stored elsewhere. No large software packages should use a direct subdirectory under the /usr hierarchy. An exception is made for the X Window System because of considerable precedent and widely-accepted practice. This section of the standard specifies the location for most packages." -- http://www.pathname.com/fhs/2.0/fhs-4.html "4.6 /usr/local: Local hieararchy The /usr/local hieararchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and dada that are shareable amongst a group of hosts, but not found in /usr. . . . This directory should always be empty after first installing a FHS-compliant system. No exceptions to this rule should be made other than the listed directory stubs. Locally installed software should be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. Note that software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software should not be placed outside of /usr/local without good reason." The conflict, as I see it, is that you are taking "local software" to mean "any software not part of the base system", while FHS does not state this. Perhaps Quinlan can clarify this. My interpretation is that "local software" means stuff the admin downloaded and installed, while "system software" is stuff that came with the system. In the case of a Red Hat system, this means alot of things that wouldn't be considered "core" utilities. Personally, I use /usr/local for non Red Hat-derived rpms (since I am a Red Hat user) and tarballs I have compiled myself. I keep only the official Red Hat rpms (and/or upgrades to those rpms) in /usr. I use /opt (which is a symlink to /usr/local/opt for purposes of space efficiency) to hold several packages which may be mutually exclusive and therefore whose normal installation into somewhere like /usr or /usr/local could conflict with one another. For instance, I have /opt/jdk1.1.7 as well as /opt/jdk1.2, I maintain (usually) the last 2 versions of netscape in /opt, etc. I have special scripts that will add the appropriate paths and settings to environment variables when one wants to use a package in /opt (for instance, if I want to open a subshell to compile using JDK1.2, I'll type 'runenv -e jdk1.2 tcsh' whereas for JDK1.1.7 I'll type 'runenv -e jdk1.1.7 tcsh'). The decision of whether to put a non-Red Hat package in /opt or /usr/local is a judgement call on my behalf. /opt is defined in the FHS, but I use it mainly for convienience and probably not in the exact way the FHS specifies. However, if there is anywhere to make your argument to put "non-standard" stuff, it would be in /opt more than /usr/local, I think. If Linux had a decent overlay filesystem, I would install every non-core package into /opt and overlay them into /usr/local or /usr. > > Yes, this will piss off EVERYONE, but, it's not the job of the LSB to > make everyone happy, it's the job of the LSB to make things "right" > where they are starting to go wrong. In the long run, everyone will be > much happier. In the short run, everyone will hate it. > > All "non standard software should go ELSEWHERE! > > This is for the good of Linux, and based on actual "good practices," > therefore, a standard for adding "non-essential software" should be put > in place. This can be done by following the basic guidelines outlined > below: > > Compilable Software. > -------------------- > Defined: Generally meaning "Open Source" but not defined to mean only > compiled on the local system from source, or only GNU or GPL. Only > meaning software that is available to users in SOME way, so that they > may compile it themselves. All GNU (and BSD and a variety of others) software is compilable by the user, therefore even "core" utilities would fall under this definition. > > Location: /usr/local/ > > Results: all software should go in /usr/local, scripts in > /usr.local/etc, binaries in /usr/local/bin. /usr/local/etc is not prescribed by the FHS. /etc is not really for scripts, although I imagine one could put some in there (except, of course, initscripts which are a little different). /etc is for configuration. > It is a MAJOR issue for Distributions to contend with. Their "packages, > should not go in /usr/bin, but in /usr/local instead. Why, FACT says, > it's not part of "Linux" it's "Linux software<period>" The problem is that Red Hat will determine what is part of Red Hat Linux, Debian will determine what is part of Debian Linux, etc. LSB should not detract from what these guys say is their version of Linux, it should just act as a subset of these, a least common denominator; so that Red Hat Linux includes all the software that the LSB prescribes to be compliant, but can include other software and still call it operating system software for their version of the operating system. Sorry, out of time for now to comment on the rest...hopefully soon... -- 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.
