RFC

[Aaron Gaudio]

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.