4 ms·

Debian packaging has a long history of being insanely hard to get right. That was certainly true in debhelper v5 and v6 times - if you wanted to package ANY sof

by bostik 13y ago

Debian packaging has a long history of being insanely hard to get right. That was certainly true in debhelper v5 and v6 times - if you wanted to package ANY software, you needed to copy-paste from an existing debian/rules and then tweak all the dh_* calls until you got a working build. It was possible to get the packaging into a "working condition" by sheer stubbornness. (Trying to learn Debian packaging from scratch was like trying to learn auto* from scratch.) With debhelper v9, and it's lovely sequencer things are a lot easier. The once-so-arcane debian/rules is now only a few lines, and as long as you set DH_VERBOSE=1, you can see exactly which internal helper gets called at any point of the packaging run. If you need to override a step, simply define "override_dh_auto_FOO" target and that's it. There's less boilerplate, and thus the packaging will be quite a bit easier to adapt to official Debian standards. So it will be (hopefully) less work for an official NM/DD to adapt your simple rules and get the package into a shape where it could be uploaded to experimental or unstable. Back in my previous life I actually wrote two or three instruction sets for random developers on how to get their software into a working debian package. And then, when the customer project manager wanted to try his hand at coding too, I came up with a bunch of reductionist scripts and templates that allowed to automatically generate a sensible debian/* hierarchy. (That effort was later taken over by developers more capable than me - and made into a proper QtCreator plugin. That thing has supported "easy debian package" system for a couple of years now...) I still can't produce packages that would pass the extremely high bar Debian sets for their packaging standards, but I sure can put together a packaging that works and is relatively easy to polish.

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.
vacri 13y ago
I found it difficult to figure out .deb packaging for our in-house services when I had a crack at it last year. There are a dozen ways to do it, with no real agreement found by my google-fu, and if you don't have a makefile, it gets even harder to find documentation to help. I saw a comment on a feature request in FPM by Jordan Sissel: "I'd think about implementing it, but there's so much silly ceremony around .deb packaging" (paraphrased). 'Silly ceremony' stuck with me. I'm sure it makes sense once you know, but there's a steep learning curve.
takluyver 13y ago
Having tried to do some Debian packaging, it still feels horribly arcane and hard to get right. I think part of the explanation lies in "If you need to override a step, simply define...". How do I know what steps there are, and what each one is doing when I don't override it? The system saves on boilerplate, but it doesn't provide new abstractions for the packaging process. So you still have to know what is actually going on, and that's harder to discover when it's being done magically behind the scenes than when it's done by boilerplate in the rules file. So it's easier for experts now, but hard for novices to get beyond the most trivial cases. Of course, the impression that it's difficult is reinforced by Debian's extremely strict standards for accepting packages.
- bostik 13y ago
  > How do I know what steps there are, and what each one is doing when I don't override it? That's what DH_VERBOSE=1 is for. Export that at the beginning on debian/rules and then do the usual "dpkg-buildpackage -rfakeroot -us -uc" dance. You will see every dh_* command being executed. If it produced any output, you'll see that too. Most of them are no-ops for small project anyway. For example: the build output will have "dh_configure", which under the hood calls ./configure with the stock debian flags. Your project doesn't use autoconf? Put this in the rules file: override_dh_auto_configure: echo "Skipping configure" Same for dh_test, or any other bit. The funky bit is that if your package needs some special treatment, you can cheat fairly easily. Just hijack a logically suitable no-op step and put the manual tweaks into the override. The verbose output shows you exactly which steps do nothing in your project. :)

by bostik 13y ago

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.

vacri 13y ago

I found it difficult to figure out .deb packaging for our in-house services when I had a crack at it last year. There are a dozen ways to do it, with no real agreement found by my google-fu, and if you don't have a makefile, it gets even harder to find documentation to help. I saw a comment on a feature request in FPM by Jordan Sissel: "I'd think about implementing it, but there's so much silly ceremony around .deb packaging" (paraphrased). 'Silly ceremony' stuck with me. I'm sure it makes sense once you know, but there's a steep learning curve.

takluyver 13y ago

Having tried to do some Debian packaging, it still feels horribly arcane and hard to get right. I think part of the explanation lies in "If you need to override a step, simply define...". How do I know what steps there are, and what each one is doing when I don't override it? The system saves on boilerplate, but it doesn't provide new abstractions for the packaging process. So you still have to know what is actually going on, and that's harder to discover when it's being done magically behind the scenes than when it's done by boilerplate in the rules file. So it's easier for experts now, but hard for novices to get beyond the most trivial cases. Of course, the impression that it's difficult is reinforced by Debian's extremely strict standards for accepting packages.

bostik 13y ago
> How do I know what steps there are, and what each one is doing when I don't override it? That's what DH_VERBOSE=1 is for. Export that at the beginning on debian/rules and then do the usual "dpkg-buildpackage -rfakeroot -us -uc" dance. You will see every dh_* command being executed. If it produced any output, you'll see that too. Most of them are no-ops for small project anyway. For example: the build output will have "dh_configure", which under the hood calls ./configure with the stock debian flags. Your project doesn't use autoconf? Put this in the rules file: override_dh_auto_configure: echo "Skipping configure" Same for dh_test, or any other bit. The funky bit is that if your package needs some special treatment, you can cheat fairly easily. Just hijack a logically suitable no-op step and put the manual tweaks into the override. The verbose output shows you exactly which steps do nothing in your project. :)