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

Packaging and installation



As I'm sure you know already, I wrote about packaging in a
recent column.  But I wanted to address a different aspect
of it here, in hopes that we'll throw out (IMO the
incorrect) idea of declaring RPM as a standard format and
instead adopt a more useful, flexible and constructive
approach to the problem.

What I propose is to take the now-defunct-Zenguin approach,
or at least as close to it as I understand what Zenguin was
trying to do.  (Pardon me if I've got it wrong.)

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. 

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.  

-Nick

-- 
**********************************************************
Nicholas Petreley   Caldera Systems - LinuxWorld/InfoWorld
nicholas@petreley.com - http://www.petreley.com - Eph 6:12
**********************************************************
.



Reply to: