One of the reasons rpm packaging is so much easier may be the way the .spec files specify the patches you need to apply against the pristine source. You have a

One of the reasons rpm packaging is so much easier may be the way the .spec files specify the patches you need to apply against the pristine source. You have a number of PatchXX definitions, and then in %prep stage you do %patchXX -p N. Compare with debian: you have debian/source/format which tells which patch format is expected. The old (and ugly) dpatch? Quilt? Native? Change the source format from one version to another and you need to respin the patch set too. Whereas for rpm you simply do a "git format-patch -o $patchdir ..." and then copy-paste the patch sequence into the specfile. I've done both. I can also see the different benefits between the two systems. Debian's requirement to have debian/changelog name to match the upstream source name is a recurring hurdle. I still occasionally forget to get it right on the first go. Then there's the split between build rules and package descriptions (debian/control vs. debian/rules). For rpm all of these are in the same file. But then you get into packaging maintainability... After all the overengineering that you feel in debian packaging, updating it evevn across bigger upstream jumps is actually easier. When upstream changes things in a big way, catching up in the specfile takes quite a bit more work. I learned this the hard way with Qt5.