Re: My ideas on LSB

[tytso@mit.edu]

   Date: Mon, 20 Mar 2000 11:42:41 -0600
   From: Codifex Maximus <codifex@airmail.net>

   Next, you reevaluate the scope of the project *again* to make sure you
   are still in scope... if the scope is too large, you pare it back no
   matter how painful that may be.  

   Getting out of scope is easy and can effectively kill a project dead. 
   Personally, I think the scope of LSB, as it stands today, is too large;
   it will be way into the year 2005 before the specification is done and
   by that time... it will be obsolete and unneccessary!

   We need a *basic* specification now that addresses the most potent
   problems.  Hey, the FHS is a great idea!  It is the very important first
   step of LSB but we must go farther... but not too far.

Indeed.  The original scope of the project was just to allow third-party
ISV's to distribute portable applications that can run on multiple
distributions.  The folks who are actually doing the work are still
focused on this goal.  It's folks like you and Jochem who have tried, in
recent discussions on lsb-discuss, to expand the scope far beyond its
original bounds.


   My preliminary analysis of the situation is as follows:

   Problems:

   Linux has no standard component location organization.  Such a situation
   makes it difficult for 3rd party software vendors to make installation
   scripts and know where to put program components.  Hey!  We've got FHS
   so this is mostly done.

Exactly.

   Linux has many different versions of libc.  Such a situation makes it
   difficut for 3rd party software vendors to provide software that works
   on the majority of the distributions AND makes it hard on users because
   installations frequently fail - causing frustration.  This is a MAJOR
   PROBLEM.

Actually, most distributions are using a relatively small set glibc
versions.  Standardizing the glibc interfaces at a binary interface
level is a major goal of the LSB, and a lot of work has gone into this
task already.

   Linux has no stadardized program installation method.  This is a minor
   problem but one, that if addressed in a competant manner, will make it
   easier for users and ISVs alike.

The current plans of the LSB is to provide a standard package format
(currently RPM), and a standard command-line installation tool which can
be executed by the user to install an LSB application. 

It will not dictate that distributions actually *use* RPM, but rather
that they provide an simple tool which can handle RPM files and install
them into the user's system.  This can be done quite easily for both
Distributions which use dpkg (for Debian and Debian derivitives, using
the alien program to install non-debian packages) and even for
distributions that don't use a package tool, like Slackware, --- a very
simple perl script will convert an RPM to a cpio archive.

   Linux has no standard GUI.  <duck>  I know this is a touchy subject
   but... it must be addressed.  We should not make requirements but only
   recommendations.  Recommendations like: Linux should have some sort of
   GUI/Desktop, the desktop should have a root menu that includes minimum
   functionality like a run function, configuration menu, information menu,
   program menu, shutdown menu.  Most WindowManagers already have these
   functions or some version therof.  All other things could go undefined
   or unspecified.  This way, the user would at least be able to go from 
   one WindowManager to another and be able to use the root menu at the
   very least.

This has been declared outside the scope of the LSB.  (You were the one
complaining about too big scopes, right?)  Realistically, right now most
of the ISV's that are porting programs to Linux (especially from other
Unix systems) are currently not using Gnome or KDE, but are rather using
raw X or Motif.

At some point the LSB will need to standardize on one or more
application GUI library sets, but not for LSB 1.0.  Note that BTW we
don't necessary have to standardize the Desktop.  It's possible to run
GNOME applications on a KDE desktop, and vice versa.  Work is still
under way to make sure than the drag and drop protocols can
interoperate, but even without this, it would be possible to run a GNOME
or KDE application on a non-native desktop, as long their libraries are
available.   Hopefully, by the time LSB 2.0 rolls around, one or the
other will emerge as a defacto standard, so we won't have to standardize
both, or have to chose sides and be accused of "killing" one or the
other.

							- Ted