DEB compared with RPM
DEB compared with RPM
Posted Feb 21, 2007 19:54 UTC (Wed) by pizza (subscriber, #46)In reply to: DEB compared with RPM by mheily
Parent article: ESR's goodbye note
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.
Posted Feb 21, 2007 20:47 UTC (Wed)
by rickmoen (subscriber, #6943)
[Link] (8 responses)
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
Posted Feb 21, 2007 21:43 UTC (Wed)
by midg3t (guest, #30998)
[Link] (7 responses)
Posted Feb 21, 2007 22:05 UTC (Wed)
by mheily (subscriber, #27123)
[Link] (1 responses)
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.
Posted Feb 22, 2007 16:28 UTC (Thu)
by pizza (subscriber, #46)
[Link]
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.
Posted Feb 21, 2007 22:12 UTC (Wed)
by ldo (guest, #40946)
[Link] (4 responses)
"Some people consider file depend[e]ncies a gross misfeature." But he doesn't explain why...
Posted Feb 21, 2007 22:42 UTC (Wed)
by branden (guest, #7029)
[Link] (1 responses)
An even better example is when file objects have the same name but are completely different applications. Think of firebird, for example.
Posted Feb 22, 2007 5:44 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Posted Feb 22, 2007 0:40 UTC (Thu)
by midg3t (guest, #30998)
[Link] (1 responses)
Posted Feb 22, 2007 15:55 UTC (Thu)
by macc (guest, #510)
[Link]
Posted Feb 21, 2007 21:24 UTC (Wed)
by mheily (subscriber, #27123)
[Link] (8 responses)
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).
Posted Feb 21, 2007 22:35 UTC (Wed)
by sfeam (subscriber, #2841)
[Link]
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.
Posted Feb 21, 2007 22:48 UTC (Wed)
by branden (guest, #7029)
[Link] (6 responses)
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.
Posted Feb 21, 2007 23:23 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted Feb 22, 2007 18:22 UTC (Thu)
by branden (guest, #7029)
[Link]
Posted Feb 21, 2007 23:28 UTC (Wed)
by dwa (guest, #24604)
[Link]
Posted Feb 22, 2007 6:29 UTC (Thu)
by zlynx (guest, #2285)
[Link] (2 responses)
Posted Feb 23, 2007 11:27 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
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...
Posted Feb 24, 2007 0:41 UTC (Sat)
by zlynx (guest, #2285)
[Link]
If you are determined to evade a proper source package, you can of course.
"pizza" wrote:
DEB compared with RPM
rick@linuxmafia.com
That page is at http://kitenet.net/~joey/pkg-comp/DEB compared with RPM
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. DEB compared with RPM
> 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
Joey Hess
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.how file dependencies can get you in trouble
That's why you can specify explicit packages, if required.how file dependencies can get you in trouble
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
There are subtle differences File dependencies
between forex RedHat and SuSE
as to how packages are named
and partitioned.
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.RPM vs DEB on technical merits alone.
Your original example for deb:RPM vs DEB on technical merits alone.
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}
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.annoyances of building an RPM
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."
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.""I don't know how, so it can't be done."
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
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
annoyances of building an RPM
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."annoyances of building an RPM