[LUNI] Why RPM instead of tar.gz

[Jean-Michel Smith]

On Mon, 19 Nov 2001 08:51:39 -0600
mjinks at sysvi.com wrote:

> 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.
True.  However, there are also a lot of "unofficial" debian packages that
work perfectly well, and apt-get source --compile works with anything as
long as the libs necessary to compile are present.  RPMS (RPM Sources)
don't work nearly as well, even within a distribution.
> 
> 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. 

My experience absolutely does not bear this out.  I have worked
extensively with Red Hat, Mandrake, and Suse boxes, none of which were
easy to maintain or upgrade WITHIN the same distribution.  Mandrake's
update facility left 50% of the boxes it was used on in an unusable state
(and yes, I did follow the procedures outlined perfectly, the problem was
with the utility and/or packages, not the user or the administrator). 
Suse and Red Hat weren't quite that bad, but they had their own troubles. 
These comments are with respect to RPMs by the Distro, for the Distro,
using the Distro's preferred upgrade procedure/utility in each case.

Debian suffers from none of these problems.  Whether rpm or deb is
inherently superior in terms of the inner workings of the packaging system
is an argument someone with more knowledge of their inner workings will
have to debate.  As for usability, upgradability, and maintainability
Debian and apt-get simply win hands down.  So much so that we've gone
through the arduous process of migrating our entire enterprise (100+
machines) to Debian.

> 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.

This is true
> 
> 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.

Ximian gnome is doing some interesting stuff ... however, I have had their
install clobber Gnome on more than one Mandrake and RedHat box, although
to be fair those were pre-releases.
> 
> That said, none of this matters if the database backing your package
> management system really is corrupted.

Which of course begs the question as to which system is more prone to such
issues, debs or rpms.  My personal experience is that rpm's database tends
to be fragile, while debs is very nearly bullet proof (not perfect, but
one heck of a lot more robust than the other distros I have worked with). 
However, my experience is anectdotal, as I have never collected hard
statistics as the only people I had to convince were myself and two
colleagues, both of whome share the same experiences, and opinions, as I.

> 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.

Perhaps not, but as I said before, I stuck to packages released by the
respective distros in question and did not go around downloading third
party packages, and I still had issues, particularly whenever upgrades
were involved.  These issues are now, with Debian, no longer a factor.
> 
> > 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.

That's not entirely true either.  Unless one is really being foolish with
tar.gzs it is very straightforward to see what has been installed using a
distros packaging system vs. what came from a tar.gz.  The latter (again,
unless someone really screws up) gets put into /usr/local, the former
under /usr.  /opt is the only place where one might wonder, in which case
a quick "rpm -q -a" or "dpkg -l" will answer the question.
> 
> 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.

Inheriting systems which have not been maintained well is frustrating ...
I inherited a bunch of old sun systems that were that way.  Nevertheless,
the segregation of tarballs (/usr/local or perhaps /opt if it is a
commercial or large 3rd party app) vs. debs/rpms is well defined, and I've
found even opt to be relatively easy to sort out).

I was never a Debian fan, and certainly not a proponent, until I
discovered about 2/3 of my workload could be eliminated by moving to it
and away from Mandrake//Red Hat.  I could go on for hours on how much time
it has saved me in the last couple of months alone, but suffice it to say
that apt-get, and to some extent FreeBSDs /ports section, have lived up
the promise that rpm has made but in my experience hasn't really
delivered.  Being able to cron up security updates so that they are
obtained automatically each week, or being able to do full-on, major
upgrades with two (!!) commands, without losing any of one's
customizations is a luxery none of the other distros has managed to
deliver, and one that has reduced my workload immensly.

Jean.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://luni.org/pipermail/luni/attachments/20011119/889260b8/attachment.bin