[NTLUG:Discuss] .debs versus RPMs

[Christopher Browne]

On Thu, 12 Oct 2000 17:13:01 CDT, the world broke into rejoicing as
"A.L." <al at 9b.com>  said:
> <snip>
> > If they could get rpm's to be as easy to work with as
> > deb's I wouldnt bother, but you only install once, you have to be able to
> > maintain it for a LONG time.
> <snip>
> 
> 	Just out of curosity, as I have seen such things mentioned before;
> but what on earth do *.deb's do that *.rpm's don't?  I've been building my
> own rpm's for years, and hacking other folks's spec files and such for
> longer than that, and I have never come across anything I wanted to do
> with a packaging system that couldn't be done with rpm's.  I don't know a
> whole lot about *.deb's, but I would be interested to know if there's some
> really cool thing or something that they'll do that rpm's won't.  Thanks
> in advance.

Inherently? While there might be a few bits of functionality back and
forth that one or the other does a little better, the point is _NOT_
that there is anything better about the two packaging formats.

Both use "standard" tools, for slightly varying values of "standard;"
both provide the ability to represent dependancies; both allow some
scheme for certifying the identity of who generated the package; both
track what files get put where, both provide checksums to allow you
to upgrade with some degree of safety whereby if you customize config
files, the custom bits don't get lost, and both start with 'pristine
source.'

The _differences_ are in two directions:

a) The "apt" tools provide a coherent way of dealing with _groups_
   of packages, both vis-a-vis:
     1.  Those that may have been collected together in a particular
         "archive," and
     2.  Those that are more directly related due to dependancies.
   The former provides a "multiplexing" way of getting at lists of
   packages to consider for installation.

   The latter provides a coherent way of trying to _satisfy_ the set
   of package dependancies that result from trying to install
   Gnumeric, that requires a boatload of Gnome 'stuff.'

   "AutoRPM" provides a somewhat similar way of coping with this; the
   merit of the Debian tools is that they are more mature and, with
   multiplexing designed in from the word go, already support a bunch of
   ways of collecting together dependancies and software archives.

b) The debian "dpkg toolset" provides tools (notably "lintian") for
   validating that what you get, after generating a package, you
   have something that conforms to the General Requirements of
   Fitting Well With The Distribution's Policies.  Having man pages, 
   locating stuff in appropriate locations, and the likes.  Probably
   lots of other stuff; I'm not quite sure what.

   There is no RPM equivalent to "lintian," and this represents a
   pretty significant part of why there have been so many problems with
   Quality Control with RPM-based distributions, and, more dramatically,
   with the "contributed" RPMs, where just about _any_ kind of rubbish
   can and has made it into "contrib/i386".
--
cbbrowne at ntlug.org - <http://www.hex.net/~cbbrowne/lsf.html>
"Running Windows on  a Pentium is like having a  brand new Porsche but
only be able to drive backwards with the handbrake on."
-- (Unknown source)