[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC

I have been a UNIX user for over 6 years now.  I have followed the LSB
since before there was a LSB.  I have seen it get tons of press, have
great ideas, and fade slowly into the background.  I think it's time for
a swift kick in the rear end!

I have looked at every angle of this issue, and after a couple years of
consideration, I feel it's time for me to stand up and say flat out what
is right, and what is wrong with the way things are going.

First off, the test suite is a GREAT idea.

Second, any issue of "software packaging" should NOT be standardized by
the LSB.

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.

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!

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.

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.

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.


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).

Issue 1)
POSIX
Linux systems that are LSB compliant will pass a standard battery of
tests, including POSIX testing.

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."

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"

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.

Implications:
According to FHS and "good Linux Housekeeping", non-standard software
should NOT, and I repeat, NOT be in /usr/bin 

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.

Location: /usr/local/

Results: all software should go in /usr/local, scripts in
/usr.local/etc, binaries in /usr/local/bin.
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>" 

In the long run, system maintainance will be much easier to cope with,
and housekeeping and upgrading will be much easier for
users/administrators.

PROBLEM: Almost all distributions (except maybe Slackware) will have to
define a "base" path, and a "normal install" path.  E.G.  Redhat's rpmrc
will have to say, install in /usr/local not /usr for almost everything. 
When installing "base" software, it will need to specify the --root /usr
flag or something.

NOTE: It is OUTSIDE the scope of the LSB to handle issues of how the
software installed in /usr/local is managed.  This is an issue to be
left to the software package handling systems (.rpm's, .deb's, .tgz's,
etc) and the software programmers (who might need to consider a "make
uninstall" along with the "make install")

I am not making light of the problem, software management IS important. 
But it is outside the scope of the LSB.  The scope of the LSB is just
what it's name implies, the Linux Standard Base.




Binary Software.
----------------
Defined: Software that for some reason is only available as a binary. 
This is most likely a result of the software bing commercial.  Although,
if the sources is provided, and it was paid for, it still goes in
/usr/local/, because /opt is for software available as a binary only.
Result: Regardless of packaging formats, installation meth9ods,
anything, all "non compilable software" will be in /opt.

This organizes the basic hiarchy of Linux.  The OS will run fine if /opt
and /usr/local are completely nuked, as should a solid LSB compliant
system.  This follows the basic standards laid out by FHS.  This is
"good housekeeping"



Acceptions:
-----------
The X Windows system itself will be in /usr/X11R6.
The X windows system is defined NOT by the LSB, but by XFree86, or
MetroX, or Xi-Graphics, or whoever.  
It is OUTSIDE the scope of the LSB to define what is and is not "X"  X
is not part of Linux, X is "software".  What is defined by the X-Windows
rendering software provider as "part of X, and not part of X" defines
what goes in /usr/X11R6/.  All software that is NOT part of X (as
defined by the provider of that software" goes in /usr/local/ or /opt,
as described above, REGARDLESS of if X is required to run that software.



Libraries:
----------
Libraries will comply to the same standards as software. 
/usr/local/lib/ is for libraries, regardless if how "standardly" used
the libraries are.  Only the absolute "standard" libraries used in
compiling "the base set" are to be placed in /usr/lib.  This means ANSI
C, C++, basics, are in /usr/lib (commercial or not, doesn't matter).  If
the libraries are "tool-kits" or commercial add ons, they will go in
/usr/local/lib, as would be the case of anything that is not part of the
"base set."



Summary:
--------
The LSB should define a base.  That base is "the OS" and not "the
software."

The LSB should define "standards" as they apply to "the base."  This
does include FHS compliance, and therefore requires the mention of
"where the software should go" but not "what it should be packaged
like."  This can be done simply by moving the "software" outside the
directory stucture of the "base OS" itself, into /opt and /usr/local.

Not all "Linux" systems need conform to the LSB.  LSB compliance shoud
be sought by all major Linux distributions, but will not be "required." 
Obvious acceptions are projects such as the Linux Router Project, and
embedded Linux projects.

Major distributions will benifit from LSB compliance, in that it will
enable all LSB compliant systems to have a "standard subset" (the OS) to
build on, contribute to, and work from.

ISV's will benifit from having a standard basis from which to work on,
knowing where thier software should install to, and knowing better how
to define any nessessary "dependancies" reguardless of which Linux
distribution thier software will be installed on.
begin:vcard 
n:Current;Robert
tel;fax:(732)329-3023
tel;work:(732)329-3090
x-mozilla-html:FALSE
url:http://www.hel-inc.com
org:Hazard Evaluation Laboratories, Inc.;Applications and Installation Engineer
adr:;;1 Deer Park Dr., Suite L;Monmouth Junction;NJ;08852-1921;USA
version:2.1
email;internet:current@hel-inc.com
title:Ph.D.
x-mozilla-cpt:;0
fn:Robert W. Current
end:vcard
Reply to: