Debian packages have a much simpler design than RPM. This makes it easy to unpack them even without having dpkg installed, as it is just an AR archive with two tarballs.
Now, some of my thoughts on your comment, from my Debian PoV:
> * Gpg verification, IIRC in RPM based systems first
Binary packages can have signatures using 'debsigs'. All source packages are GPG-signed and the package repositories are signed as well, and supported since apt 0.6 in 2003 (though it took some time until the main archive was signed for the first time).
> * Multi-lib support (next Debian release goal)
Well, at least Fedora had the problem that it always installed packages for both architectures, although they were useless for me. But that was a long time ago.
> * Automatic debug info generation (next Debian release goal)
Yes this will come.
> * Delta RPM integration
We have debdelta.
> * Separate patches
What do you mean?
> * File capability support?
Write a script to set them. But I don't think we really need them at the distribution level.
A possible change of direction for Foresight Linux
Posted Aug 16, 2009 16:43 UTC (Sun) by rahulsundaram (subscriber, #21946)
[Link]
Multilib - Fedora has not installed both arch packages by default in a x86_64 system for quite sometime now although there is a simple setting to change if you prefer it.
DebDelta is not integrated into the distribution like DeltaRPM in SUSE and Fedora after that.
Separate patches - RPM has always used granular patches unlike Deb where usually many of the patches are put up into a single archive. This makes it harder to cherry pick some of them. I know this isn't always the case.
File Capability - Writing a script is fragile. Fedora is going to use this RPM capability by default in the next release
If you want more, Fedora is also using XZ compression by default in the next release as well. My point is simply that catching up is bound to happen on both sides.