[LUNI] Why RPM instead of tar.gz

[mjinks at sysvi.com]

On Mon, Nov 19, 2001 at 08:19:54AM -0600, Jean-Michel Smith wrote:
> 
> I'd have to second this discontent with RPM.  It is the main reason I
> switched from Mandrake (which was otherwise a very nice system with the
> smoothest install I've ever seen) to Debian (which has a fairly demanding
> install, but oh so worth the trouble).  With Debians .debs and apt-get one
> can maintain and upgrade a system with virtually no hassle whatsoever. 

Blame where blame is due: most of the issue with RPM vs. DEB isn't the 
package management system itself but the process by which something gets
to become a package.

RPM: lots of distros and even other Unices use it.  Anybody who wants to
can compile a package as an RPM and maybe get it listed with e.g. rpmfind.net.
Thus there are packages out there which won't work on your system, or won't
work with other packages on your system, and there could be packages that are
just crap and won't work at all; it all comes back down to the admin of the
box and his/her ability and willingness to test and maybe fix packages to
run on the box.

DEB: ein volk, ein package repository. ;)  The reason why people say that
apt-get does such a good job of resolving dependencies is because there are
humans who maintain an authoritative repository where everything has already
been checked against everything else.  As long as you stay within the distro
you started out with, that's true of RPM just as well.  But of course the
downside is that as soon as you need a package or version that hasn't made
it to your distributor's official repository, you're either stuck waiting or
you're compiling from source, either into a package or not but still you're
on your own.

All of this is one of the reasons why I like Ximian GNOME for newbies.  With
Red Carpet they're doing something a lot like apt-get, but distribution
agnostic, there are .deb and .rpm versions available depending on which of
maybe eight or ten distros you're on.

That said, none of this matters if the database backing your package
management system really is corrupted.

> Even nicer in some ways is FreeBSD's /ports packages, which automagically
> download and compile packages with a simple "make" install.  (apt-get
> source [package] --compile; dpkg -i [package].deb is similiar.)

You get the same thing with source RPM's.  Same deal: if the package isn't
pre-vetted, probably by a human, to work with your distro, you may be in
for some trouble.  But this isn't a big difference in the package system
per se.

> Your preference for *.tar.gz files (and cvs source) is shared by many
> (myself included).

.tar.gz's are great if you know that (a) you'll remember everything you've
done (and of course we all document every last change we make to every last
box we run, right?  suuuure.) and (b) you're the only person who will ever
have to admin that box.

When I step into a new gig I often find machines which have been maintained
by two or three different people, each with their own peculiar way of doing
package management; applications installed in /usr/local, in /opt, in 
/opt/pkg, and Bog knows where else.  There is just NO way to examine a 
system like that in any kind of short order to find out what it does, what
state of health its packages are in, whether there are duplicates... and
I always end up wasting a lot of time trying, when what I'd really prefer
to do is just wipe the sorry mess and start out from a known state, ANY
known state, rather than having to read the mind of one or more admins who
I've never even met.

Even if you only ever want to use source tarballs on your machine, and no
matter which package management system you have, there should be a way
to incorporate those tarballs into your package database so that people like
me won't have to tear our hair out trying to figure out what you've done.
With RPM it's the spec file, I assume there's something similar with .deb's
and .pkg files but I haven't had occasion to learn either of those yet.

Cheers,
-m