THE TIME HAS COME TO PACKAGE UP STANDARD, COMMERCIAL
     INSTALLATION ISSUES FOR LINUX AND LSB

     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.


   Miguel A. Bola�os H.
   Systems Engineering
   Universidad Latina


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


--
�Desea desuscribirse? Escriba a [EMAIL PROTECTED] con
el tema "unsubscribe".

Responder a