OFFTOPIC: NICHOLAS PETRELEY: "The Open Source" from InfoWorld.com, Wednesday, October 18, 2000
Sorry for the off-post, but I thought there'd be interest.
mike
THE TIME HAS COME TO PACKAGE UP STANDARD, COMMERCIAL
INSTALLATION ISSUES FOR LINUX AND LSB
Posted at October 13, 2000 01:01 PM Pacific
LAST WEEK I PETITIONED for tangible, far-reaching
results from Linux Standard Base (LSB), and I hope you
will demand them in a timely manner. Among many other
things, I asked for a comprehensive self-hosting
sample implementation of an LSB-compliant Linux
distribution. In plain language, that means I want a
standard Linux distribution anyone can install and
run. Every commercial and nonprofit Linux distributor
would start with this standard then add the unique
kind of value that does not cause incompatibilities.
Paul Thomas, CEO of TurboLinux, outlined a similar
vision recently in an article published by CNet. In
it, he says he envisions the consolidation of Linux
distributions such that everyone ends up using the
same basic distribution. Personally, I don't care
whether the result comes from commercial consolidation
or consolidation of Linux distributions through
standards. All I care about is that we get there.
LSB currently does not officially plan to deliver a
comprehensive self-hosting standard implementation.
Depending on who you talk to, it is either a terrific
or horrific idea.
That is a big mistake that leads to other mistakes. For
example, if one could agree on a self-hosting
standard, one can solve lots of packaging and
installation problems that the LSB does not address.
Right now LSB is going to declare RPM the standard
package format and leave it at that. By doing so, LSB
is missing the point of what users and developers
really need. They don't need to be told what package
format to use; they need a cohesive and intelligent
plan for installing and updating applications.
I'm talking about a policy of how applications must be
installed and configured, how dependencies are
defined, and how the installation and removal process
should address unmet dependencies. By dependencies, I
mean other applications and libraries that an
application may need to run properly. LSB also should
define the protocol for updating those application
libraries, adding new versions of libraries, and then
set rules on how applications must look for and use
those libraries.
The Debian GNU/Linux installation system is still a
work in progress, but it could be an excellent start
in solving these types of installation issues.
Debian's system creates a catalog of all the
applications that exist on any number of servers or
other storage resources that you define. When you use
the "apt-get" command to install a package, it
automatically finds where to get the package you want
and attempts to resolve the package's dependencies. If
necessary, it removes whatever conflicting versions
you may have on your system and installs the correct
newer versions. Then it installs and configures the
package you want.
In addition, LSB should start with the above system and
add things such as a finer granularity of upgrade
choices. (I'm told that the Red Hat Network has this
kind of granularity, but I haven't tried it yet. Also,
I'm no expert with Debian yet, so there may be a
degree of granularity it has of which I am not aware.)
Then LSB could add checkpoints and rollback to the
process to give an administrator the ability to
recover from unforeseen consequences of performing an
upgrade. Of course, LSB should make it a goal to
prevent rollbacks from ever being necessary.
Naturally, this requires a Herculean effort, but would
it be much more difficult than what the Debian
maintainers already do?
Now if you think this through, you'll see that this
whole approach is only practical if every distribution
plays by the same comprehensive set of rules. And
those rules far exceed the tiny set of rules currently
slated for the LSB 1.0 specification. So for this to
work, LSB needs to dramatically expand its scope.
In addition, this will work only if some organization
like the LSB or in cooperation with LSB hosts a server
farm where anyone can get at the packages required to
resolve dependencies. This server farm will have to
host existing and future versions of libraries and
packages to guarantee that someone will be able to
roll back properly in the event of a problem.
Are there other issues you believe LSB should address?
Let me know.
Nicholas Petreley is the founding editor of Linux World
(http://www.linuxworld.com). Reach him at nicholas.petreley@linuxworld.com.
Copyright 2000 InfoWorld Media Group Inc.
Reply to: