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

Re: Packaging and installation

   Date: Mon, 23 Oct 2000 15:40:10 -0700
   From: Nicholas Petreley <nicholas@petreley.com>

   One of the many problems with declaring RPM as a package
   format is that it tries to resolve dependencies through the
   RPM database.  So if you install anything that a program
   needs via any other method besides RPM, then RPM will
   consider dependencies unresolved even though the
   programs/libraries a new package needs may actually be
   present.  This makes RPM unnecessarily restrictive and
   actually counterproductive to compatibility.  The answer so
   far as been "ok, then use alien", but that's not realistic. 
   Alien is far from perfect, and then you're stuck with
   either switching to RPM (IMO an unacceptable option) or
   dealing with the problems it causes.

   Instead, we should define an installation protocol that
   looks for programs and libraries within the filesystem
   itself in order to detect if dependencies are met.  There
   are other aspects of the installation protocol we should
   address, such as how configuration file conflicts are
   handled.  And I'm sure there are several other issues we
   could address that I won't bother with in this post. 

What do you mean by this, precisely?  When you talk about "protocol",
exactly what is communicating with whom?  If you could flesh out this
idea some more, it would be easier to judge it.

I will note that it's still necessary to put all of the files into some
kind of convenient single-file "package" format.  And in fact, if your
protocl is simply "a shell script", you can do this with RPM and use its
pre-install script for your "installation protocol" to check whether
programs/libraries are present.  The one thing which is necessary (and
for which I'm not sure whether or not RPM provides this) is that a way
of aborting the install if the requirements aren't met (for example, by
having the pre-install script return a non-zero exit status).

   The result would be this:  If the RPM maintainers want to
   rewrite RPM to take this into account (even in addition to
   or in place of searching the RPM database), it would make
   RPM compliant.  I don't know how .deb works behind the
   scenes, but there's no reason that couldn't be adapted to
   this protocol, as well.  And it would be simple to write an
   installation utility that uses tgz files and still follows
   our protocol.  

I think we still need a common file format.  Otherwise, exactly how does
the user experience work?  You have't really provided enough details for
us to judge your proposal fairly....

						- Ted

Reply to: