Seeking consensus on dh

Posted Jun 6, 2019 4:37 UTC (Thu) by anguslees (subscriber, #7131)
In reply to: Seeking consensus on dh by filbranden
Parent article: Seeking consensus on dh

There is a single way to package everything, and that is the `./debian/rules` (makefile) script. It is provided various standard arguments and environment variables, and expected to (eventually) produce .deb and other output files.

Naturally writing similar debian/rules boilerplate for similar upstream packages is undesirable, so various "helper" tools have been developed over the last few decades. It's easy to see why the "best" tool for a python module might not be the best tool for a kernel module, or a font.

To me (coming from the Debian world), it's horrifying that rpm mandates a centralised set of rpm functionality across such diverse needs ;) Imagine what we'd be stuck with if the the original dpkg standards had mandated whatever the most popular helper was 20+ years ago, without experience or a process for change!

to post comments

Seeking consensus on dh

Posted Jun 6, 2019 9:26 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

This sounds like the same argument about autoconf/automake versus various other build systems. The standard way to build is with a Makefile; but of course you don't want to write that all by hand every time, so we need this helper script to generate it... Before you know where you are you're in a world of m4 macros, self-configuring shell scripts that generate other shell scripts, and generally a tower of abstraction that makes some things easy but other things very hard.

You could choose to simplify all that by having a build tool like scons or meson which works from a single configuration language and has richer built-in functionality than plain old make. And if there are certain projects where the tool doesn't work well, it might be a better investment of time to adapt it for them, rather than pay the cost of having lots of different build systems.

You are right, the best tool to generate debian/rules for a Python script might not be the best tool to generate it for a kernel module. But there is an implicit assumption: that you need to generate the debian/rules file at all. Perhaps a better build system would start with a less verbose configuration file that doesn't need to be generated, but can be handwritten without too much boilerplate.

Seeking consensus on dh

Posted Jun 6, 2019 9:56 UTC (Thu) by smurf (subscriber, #17840) [Link]

Well, "dh" basically allows you to write a less-verbose configuration file -- debian/rules now consists of five lines of fixed boilerplate. You might want to set what dh calls the build system (Python packages don't have Makefiles), but that's it, at least to start with.

Yes, building Haskell needs a "dh_haskell" helper. I'm reasonably positive somebody will write one, now that CDBS is on its way to being deprecated.

Seeking consensus on dh

Posted Jun 6, 2019 15:33 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link]

Isn't applicable here at all. The 'standard' way to build a .deb-file from a debianized soucre tree is to use the debian/rules Makefile to build a target called 'binary' (unchanged since at least 1999). 'dh' is a set of tools implementing a sequence of steps for building a debian/rules target. For the most simple case, the rules will just contain

%:
dh $@

ie, whatever target is supposed to be built, build it by invoking the dh program with the target name as argument. 'dh binary' ends up executing 50 dh subcommands in a certain sequence, all of which can be overriden individually by putting Makefile targets named 'override_dh_<something>' with dh_<something> being a dh subcommand into debian/rules which will be activated instead of the default commands if they exist.

This is a pretty flexible and nevertheless easy-to-use approach: The most complicated Debian package I've created so far overrides just eight of these 50 subcommands and usually, the overrides just do something in addition to the default operation.

Seeking consensus on dh

Posted Jun 10, 2019 8:42 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (1 responses)

RPM has a lot of duplication. All those postinst scripts that dh_whatever generate are not automatically generated.

Seeking consensus on dh

Posted Jun 10, 2019 11:31 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> RPM has a lot of duplication. All those postinst scripts that dh_whatever generate are not automatically generated.

It depends on how you write spec files. The recommended practice in distributions that use RPM like Fedora have been to move away from scripts to macros and file based triggers that avoid said duplication. Scriptlets should be reserved for a one off use cases.