4 ms·

Yes, I maintain Fedora and Debian packages for my upstream project (I'm not a Debian developer - I pass my package to a sponsor). Debian is much harder to get

by xioxox 13y ago

Yes, I maintain Fedora and Debian packages for my upstream project (I'm not a Debian developer - I pass my package to a sponsor). Debian is much harder to get right, though I do have more experience maintaining Fedora systems. The Debian packaging process seems an order of magnitude more difficult to get right, mainly because of the magic documented in various scattered documents and the many different build systems. I've yet to find a good document explaining how all this stuff interacts with each other. rpmbuild is much more conceptually easy to understand for me. You also have more boilerplate documents (e.g. copyright), that Fedora doesn't care about. Fedora also has a nice system where you can get builds done on a server with various architectures and for different releases.

bostik 13y ago
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.

by xioxox 13y ago

bostik 13y ago

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.