I have the exact oposite experience. Building/packaging/maintainig my own software with RPMs is pretty straight foreward, whilst packaging the same software as .deb is a rollercoaster which often goes off track and down a deep hole.
RPM makes the simple easy and the difficult impossible. RPM's grace and sin is its simplistic, rigid, singular spec file.
The startup costs to Debian packaging are greater. In the most basic case not that much greater--a single control file with intuitive fields, and a rules file (i.e. Makefile) with intuitive targets. However, to do things according to best practice (i.e. official Debian policy) often requires using additional tools and configuration files. So, yeah, it can become byzantine. But if you realize that it all comes back to generating that control file and rolling up a target directory, same as RPM, it can be easier to make sense of everything.
The important distinction is that all the complexity, required and optional, in Debian packaging can be hidden within the confines of the packaging framework. That is, whatever your build rules and workarounds, anyone trying to build your package can just invoke a standard dpkg build without having to understand any of it. Working around deficiencies in RPM often requires adding and exposing additional layers of complexity, like generating spec files in ad hoc pipelines before a user can invoke rpmbuild.
For example, do you autogenerate your RPM package version from the source? How do you embed it within the spec file? And are you able to also generate a source tarball that can generate the same build? It's one thing to cobble together an RPM that explodes to some binaries; it's another to do so in an automated fashion that's also transparent--i.e. generates SRPMS that can be built within clean environments. I know, I know, CI/CD systems can obviate the need to build binary RPMs from SRPMs, but that's exactly my point. RPM alone is seriously deficient. There are lots of little problems like this that pop up when your needs become more complex; you end up building taller towers of complexity than what would be needed using Debian.
You can build with rpmbuild without making SRPMS (pass -bb instead of -ba), but in my experience, most CI/CD systems do not provide clean, arbitrarily reproducible environments.
That said, rpmbuild has grown features over the years to make it more compatible with that model.
My experience with RPMs, Debian packages, and various other formats has led me to prefer some of the rigidity and explicitness of rpmspec over the sprawl of automagic that is a debian/ tree, and other similar things. But if you want to do weird things to build packages, nothing stops you from doing that and using a trivial spec file as the intermediate to pass instructions to rpmbuild to wrap it up.
The format is not perfect, but I haven't seen anyone make any proposals recently about how to improve it on the rpm-ecosystem mailing list, the rpm-maint mailing list, the rpm project on GitHub, or at any of the developer conferences where rpm developers show up.
You seem to have a ton of knowledge and opinions, why not engage with the project?
reply