On Tue, Nov 07, 2000 at 10:59:59AM -0500, elawson wrote:
[snip]
> While many things seem to be around in rpm format, the completeness of the
> deb packages is amazing. If you need a package, it is there and you do not
> need to worry about missing a lib. For me, it is far better than RPM.
[snip]
Okay, I'll bite. This is a rant, but at the end, I have a request. I've
been want to do an honest comparison of rpm and dpkg for some time now. I'm
definitely partial to Red Hat and rpm, but if I'm shown that Debian's dpkg
tool truly has benefits that outweigh its drawbacks, than I'm willing to
change my view.
However...I once tried to build a debian cross development environment for
Red Hat. In other words, I wanted to be able to build deb packages from
source code on a Red Hat box. I considered it (and still consider it) a
worthy goal, but I gave up in frustration. In my limited experience learning
what I had to about the dpkg tools to try to get a cross development environment
I was disappointed to find a few things missing from the dpkg tools, or more
properly, from the philosophy:
o There doesn't seem to be any such thing as a 'source package'. You
need the .dsc file, the tar-gzipped source, and a possible *single* patch
file. Although this does in the strictest sense follow the 'pristine
sources' principle that is followed almost religiously by Red Hat, it
doesn't sit quite right with me. One large jumbo patch, IMNSHO, is
not a great way to package the changes. Patches should be separated
out into what they do or fix functionally. That way it's easy to
disable certain 'fixes' that you may not want and easily rebuild the
package without those changes, but including all other changes. And
do this without ever touching a single .c, .h, or Makefile.in.
Your stuck with a very inflexible single jumbo patch.
o I also like a single 'source package' file so all I need to do is move
a single file to, for example, another hardware platform (netwinder
anyone?) and type 'rpm --rebuild <source-rpm>' and voila! -- provided
there are no platform specific fixes needed for the new platform, I
have a new binary rpm. And I needn't fear that I've got the wrong
dsc file paired my tar-gzipped file.
o Packages seem to be FAR too dependent on pre/post install/uninstall
(PPIU) scripts. Most of the scripts I looked at are HUGE. Now I don't
want to be accused of same naivete/idiocy of the Microsoft rep
on some panel a while back who said (paraphrased), "the need for
scripting indicates a weakness in an operating system." But there
is a grain of truth in that statement. The length of these scripts,
and the fact that many of them are largely similar but not similar enough
to become a standard part of dpkg, does, in fact indicate a weakness in
the packaging tool. I've seen many, many rpms with NO PPIU scripts
and many more that are only a single or just a few lines long.
o Though this can probably be turned off with an option, I dislike dpkg's
intense verbosity by default. An 'rpm -i <package>' spits out *nothing*
by default, which, IMO, is as it should be.
o I had a discussion by proxy (don't ask) with a third party vendor who
was bitching incessantly about rpm. His contention was that a packaging
tool should be able to query the user for input via PPIU scripts, which
rpm can't do. Frankly, I vehemently disagree with this. As a system
administrator, I want to know that I can do batch installs or upgrades
of packages without being prompted for ANYTHING. For the proper (IMO)
way of doing this, look at what VMware does with its rpm: They plop
a script called vmware-config.pl in /usr/bin and spit out a message
the instructs the user to run this script before running the product.
This gives the installer much more control over the installation.
Just install the freakin' thing and let me do ALL of the configuration
later.
So you may say 'why not provide the feature and let the packager
decide.' I know all the arguments about choice, in the Free Software
world, but this one choice that should be up to the system administrator
installing the package. Just take a look at the commercial products
available for Solaris that are packaged with pkg tools, and you'll see
that querying the system manager incessantly for information during
the install is abused quite consistently.
Now comes the request. I seriously challenge anyone with lots of dpkg
experience, and at least some minimal experience with rpm, to come up with
a set of reasons why he thinks dpkg is better than rpm. But here's the
catch, which relates to elawson's comment quoted above: Do this without
ever mentioning the apt tools or referencing their functionality. Why?
Because in my mind the apt tools are a layer above the packaging tools.
They don't generally store dependency information, they USE it. They don't
install packages, they decide what to install, download them, and USE the
package tools to do the install.
From what I can tell, the apt tools are far better than the various
attempts at similar tools (autorpm, up2date) for rpms. But rumor has it that
apt has been retro-fitted to work with rpms now. Assuming that this is
true and that the apt tools for rpm are as functional as the apt tools for
dpkg, can anyone argue that the pairing of apt and dpkg is still better
than apt and dpkg? If so, I await your answer. No sarcasm intended ...
I'm waiting to be slapped down so I can do a truly honest comparison for
others in my company. The reason I haven't done it yet is because I haven't
found anyone with enough serious experience (including building packages)
with dpkg.
So there it is. I await your flamethrowers with asbestos underwear. :-)
--
-Paul Iadonisi / Consultant / Red Hat Certified Engineer
Collective Technologies - Managing Systems and Networks
Team Yankee, Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
