3 ms·

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

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. :)