RPM vs DEB on technical merits alone.

RPM vs DEB on technical merits alone.

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