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: