| |||||||||||||
DEB compared with RPMDEB compared with RPMPosted Feb 21, 2007 18:45 UTC (Wed) by mheily (guest, #27123)Parent article: ESR's goodbye note
I have worked with both formats, and IMHO, DEB is a vastly superior to RPM as a packaging format. DEB is easier to use, better documented, more modular and extensible than RPM, and uses standard tools (/usr/bin/make and shell scripts) instead of a custom tool (/usr/bin/rpm). There is no limit to what you can do with a combination of a Makefile and shell scripts.
An RPM spec file is basically comprised of four things: macros, tags, a list of files, and build/install/uninstall scripts. All of these things are jammed together in a single file that becomes bloated and hard to read -- especially when a lot of macros are used. The spec file is processed by a single, monolithic tool (/usr/bin/rpm) to produce a binary package.
By contrast, all Debian packaging information is kept in small, single-purpose files under the debian/ directory. The entire build process is controlled by a Makefile named debian/rules. The Makefile calls a number of small, single-purpose shell scripts provided by the 'debhelper' package to do the actual work. For example, if the package needs to install an entry in the system crontab, you add a line to the Makefile that calls the dh_crontab script, which merges the contents of debian/cron.d file into the system cron.d directory.
I'm not aware of an equivalent to debhelper in RPM, which means that packagers have to roll their own system-dependent scripts to do all the work that debhelper does for you.
(Log in to post comments)
DEB compared with RPM Posted Feb 21, 2007 19:17 UTC (Wed) by ncm (subscriber, #165) [Link] It's easy to construct a .rpm archive. Make a .deb archive, and then convert it with alien.
:-)
DEB compared with RPM Posted Feb 21, 2007 19:54 UTC (Wed) by pizza (subscriber, #46) [Link] The benefits you're describing aren't a result of any superiority to the 'deb' package format, but rather Debian's strict packaging policies.
RPM doesn't provide policy; the distribution-provided macros do. Where the macros don't provide policy, you need to look to the packaging guidelines.
Those "debain/Rules" helper scripts sound suspiciously like "system-dependent scripts to do all the work".
Note this is the same distinction as "the deb tools" vs "Debian's use of the deb tools".
Please, compare apples to apples. If you want to critique RH/Fedora's past packaging policies vs Debian's, fine. If you want to critique the featureset of the automagic-package-dependency-resolver-and-installers (aka apt and yum), fine. If you want to compare the technical capabilities of the dpkg format and tools versus the rpm format and tools, fine.
But don't go comparing a set of packaging policies to the tools used to implement said policies.
Oh, and finally, 'rpm' has not been monolothic for some time; the package builder (rpmbuild) uses quite a few modular tools, scripts, and macros to assemble packages.
DEB compared with RPM Posted Feb 21, 2007 20:47 UTC (Wed) by rickmoen (subscriber, #6943) [Link] "pizza" wrote:Please, compare apples to apples. If you want to critique RH/Fedora's past packaging policies vs Debian's, fine. Well said, sir. In my view (as well), people making handwaving claims about merits of these two perfectly serviceable package formats should be gently lead to Joey Hess's indispensible "Comparing Linux/UNIX Binary Package Formats" page, and advised to please make certain their comments are informed ones. Rick Moen
DEB compared with RPM Posted Feb 21, 2007 21:43 UTC (Wed) by midg3t (subscriber, #30998) [Link] That page is at http://kitenet.net/~joey/pkg-comp/
DEB compared with RPM Posted Feb 21, 2007 22:05 UTC (Wed) by mheily (guest, #27123) [Link] I should have said 'package build system' instead of 'package format' in my earlier comment, because the two formats *are* similar at the low level of detail that Joey Hess is talking about. They both contain a collection of files that can be installed and uninstalled, and contain scripts that run during the install and uninstall process.
The point I was trying to make is that the mechanism for defining and creating a DEB package is superior to the mechanism for defining and creating an RPM package. This is part of the reason why Debian packages are 'better' than RPM packages; the power and flexibility of the build system allows you to design better packages with less effort, which makes the end user's life (and now ESR's life, apparently) easier.
DEB compared with RPM Posted Feb 22, 2007 16:28 UTC (Thu) by pizza (subscriber, #46) [Link] > The point I was trying to make is that the mechanism for defining and creating a DEB package is superior to the mechanism for defining and creating an RPM package. This is part of the reason why Debian packages are 'better' than RPM packages; the power and flexibility of the build system allows you to design better packages with less effort, which makes the end user's life (and now ESR's life, apparently) easier.
There is no (major) technical reason why Debian couldn't switch to RPM, or Fedora switch to DPKG as the packaging format.
"Fedora on dpkg" will be indistinguishable from the current "Fedora on rpm". Likewise, "Debian on rpm" would be indistinguishable from the current "Debian on dpkg". As there is no technical benefit to doing so, there's no point in wasting everyone's time for a non-feature.
The "end-user's life" is "easier" precisely because of Debian's packaging policies. While the tools may have features to help facilitate said policies, the policies drive the tools, not the other way around.
Both Fedora's and Debian's strengths (and weaknesses!) lie in their policies, not their tools. Both distributions still have different goals, and their policies reflect those goals.
Joey Hess Posted Feb 21, 2007 22:12 UTC (Wed) by ldo (subscriber, #40946) [Link] "Some people consider file depend[e]ncies a gross misfeature." But he doesn't explain why...
how file dependencies can get you in trouble Posted Feb 21, 2007 22:42 UTC (Wed) by branden (subscriber, #7029) [Link] Having a file dependency on /usr/bin/make when you're going to rely on GNU extensions to Make (and there are several), is a bad idea.
An even better example is when file objects have the same name but are completely different applications. Think of firebird, for example.
how file dependencies can get you in trouble Posted Feb 22, 2007 5:44 UTC (Thu) by bojan (subscriber, #14302) [Link] That's why you can specify explicit packages, if required.
File dependencies Posted Feb 22, 2007 0:40 UTC (Thu) by midg3t (subscriber, #30998) [Link] Searching the package namespace for a dependency is much more efficient than searching through the file list of every package. More importantly, as mentioned by branden, it allows automated dependency resolution to install the right package.
File dependencies Posted Feb 22, 2007 15:55 UTC (Thu) by macc (subscriber, #510) [Link] There are subtle differencesbetween forex RedHat and SuSE as to how packages are named and partitioned.
RPM vs DEB on technical merits alone. Posted Feb 21, 2007 21:24 UTC (Wed) by mheily (guest, #27123) [Link] The packaging policies have nothing to do with it. The mechanism to create a DEB package is more powerful, understandable, and flexible than the mechanism to create an RPM package.
DEB uses a Makefile to control the package build process. DEB packages use a separate subdirectory to contain packaging-related files where each file has a specific purpose. DEB provides shell scripts (debhelper) that you can use in your Makefile rules.
RPM uses a custom packaging tool (rpmbuild) to control the package build process. RPM combines all packaging information into a single specfile. RPM provides macros which are expanded into Makefile rules.
What debhelper provides is convenience scripts so you don't have to write your own Makefile rules for common tasks. My crontab example showed how you could install and uninstall a crontab(5) entry by adding a single line to the debian/rules Makefile. Perhaps there are system-specific RPM macros you could use to do the same thing -- but I doubt it. More than likely, you will have to add a line to the %postinstall section that has a bunch of system-specific macros such as:
cp %{_sharedir}/%{pkgname}/cron.entry %{_sysconfdir}/cron.d/cron.daily/%{pkgname}
And then you have to add a corresponding line to %postremove saying:
rm %{_sysconfdir}/cron.d/cron.daily/%{pkgname}
Whereas in a DEB package, you simply add a Makefile rule that says:
dh_installcron
And the debhelper script generates the code necessary to install and uninstall the crontab entry. It takes care of the details, without the use of system-specific macros or directory layouts.
Makefiles combined with shell scripts are much more powerful and flexible than macros. AFAIK, the macros in RPM can only used for lexical transformation and substitution. Shell scripts are like functions and can take arguments on the command line, produce debugging output, call other shell scripts, etc.
And you're right -- the rpm(1) utility was so bloated in the past that the package building bits were broken out into a separate rpmbuild(1) executable. I still don't see the need for a special-purpose executable to manage the package build process when we already have a great, universal and time-tested tool for building software: make(1).
RPM vs DEB on technical merits alone. Posted Feb 21, 2007 22:35 UTC (Wed) by sfeam (subscriber, #2841) [Link] Your original example for deb:For example, if the package needs to install an entry in the system crontab, you add a line to the Makefile that calls the dh_crontab script, which merges the contents of debian/cron.d file into the system cron.d directory. Your example for rpm: Add a line to the %postinstall section that has a bunch of system-specific macros such as: cp %{_sharedir}/%{pkgname}/cron.entry %{_sysconfdir}/cron.d/cron.daily/%{pkgname} So for deb you have to write a system-specific cron.d script, place it in a directory, add a line to the Makefile. For rpm you add one one line to the spec file. And from this you conclude that the deb process is more convenient? OK. To return to comparison of higher-level tools, I think any discussion of rpm is incomplete without mention of the excellent urpm meta-tools that let you manage queries, updates, and installations from multiple repositories.
annoyances of building an RPM Posted Feb 21, 2007 22:48 UTC (Wed) by branden (subscriber, #7029) [Link] The thing I find most annoying about building RPMs is that I can't just build them from source in a straightforward manner. Not with "rpmbuild" as an unprivileged user. I have to tar up the tree, compress it, and install it in /usr/src/redhat/SOURCES, and the last step requires root privileges.
An unpacked Debian source package -- or a brand-new package you've just created -- is as easy to build as "debian/rules build", and you don't need root.
If there's an easier approach than this, my RPM-savvy co-workers have not shared it with me.
"I don't know how, so it can't be done." Posted Feb 21, 2007 23:23 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] One line in .rpmrc suffices to set up a different build area. You don't need to be root.
"I don't know how, so it can't be done." Posted Feb 22, 2007 18:22 UTC (Thu) by branden (subscriber, #7029) [Link] JoeBuck, thanks, even if your subject line is a pretty flagrant distortion of my message. I did say, "if there is a way, my [...] co-workers have not shared it with me."
annoyances of building an RPM Posted Feb 21, 2007 23:28 UTC (Wed) by dwa (subscriber, #24604) [Link] http://myy.helia.fi/~karte/linux/doc/rpm-build-as-user.html covers the basic options you need to do so.
annoyances of building an RPM Posted Feb 22, 2007 6:29 UTC (Thu) by zlynx (subscriber, #2285) [Link] RPM builds everything from scratch so that you never end up in the situation where the .src.rpm cannot rebuild the .rpm.
annoyances of building an RPM Posted Feb 23, 2007 11:27 UTC (Fri) by khim (subscriber, #9252) [Link] This mechanism can be easily circumvented (homework: find at least 5 ways to do so) and thus again we are returning back to policy. Basically it's Windows approach: we'll forbid you to do this because you don't deserve to have control. Sad to have this misfeature in *nix tool...
annoyances of building an RPM Posted Feb 24, 2007 0:41 UTC (Sat) by zlynx (subscriber, #2285) [Link] Perhaps I should have said that you can't do it as "Just a quick hack to fix the build, I don't have time to do it right."
If you are determined to evade a proper source package, you can of course.
DEB compared with RPM Posted Feb 21, 2007 20:43 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] as I understand it, the .deb dependancy syntax is more flexible than the .rpm syntax
besides just saying 'A depends on B' there is more flexibility to say things like 'A suggests B' or 'A recommends B'. I also think there is more flexibility in saying that 'A satisfies any dependancies that require B'
I think that yum layers some of this on top of .rpm, but it's available even with apt and dpkg with .deb
|
|||||||||||||