On 2019-05-13 17:58:47, Thomas Goirand wrote: > On 5/13/19 3:57 PM, Marco d'Itri wrote: > > On May 13, Sam Hartman <leader@debian.org> wrote: > > > >> As promised, I'd like to start a discussion on whether we want to > >> recommend using the dh command from debhelper as our preferred build > >> system. > > I have already asked this last time, but nobody answered. > > I use debhelper in all of my packages but I have never switched to dh: > > why should I bother? > > "Everybody is doing this" is not much of an argument. > > > > Would dh really make a debian/rules file like these simpler to > > understand? Can somebody try to win me over with a patch? :-) > > > > https://salsa.debian.org/md/inn2/blob/master/debian/rules > > Without looking much, without checking if the package even builds, > here's a possible result: > > https://salsa.debian.org/zigo/inn2/blob/master/debian/rules > > Admittedly, I haven't understood all of the hacks you did (what's the > $(no_package) thing for?). > > It's only 15 lines shorter, but that's not the point. The point is that > it only declares things you are not doing like everyone else. > > Now, I have another example, which is quite the opposite one of what you > gave as example: > > https://salsa.debian.org/openstack-team/debian/openstack-debian-images/blob/debian/stein/debian/rules > > Why would one want to switch that one to something else? The package, > basically, consists of a shell script and a man page only. The > minimalism of this package doesn't require an over-engineered dh > sequencer, does it? I'm happy the way the package is, and I don't think > I'd switch to the dh sequencer *UNLESS* someone has a better argument > than "it's new", or "debian/rules will be smaller", or even "it's going > to evolve without you even noticing it" (which is more scary than > anything else, which is IMO one of the defects of the dh sequencer). This example is indeed interesting, but IMO for the opposite reason. The last commit on this file was to fix #853907 which is about the intricacies of exactly which targets to call in which sequence for the package type. Which dh avoids, because it has logic to do things rather than require the human to write the exact code needed - since we don't have (or didn't have at that time) good enough pre-upload tests. So in this case, wouldn't dh have completely avoided the bug? Very side note: why is that package a binary package instead of arch-indep, if it contains only a man page? regards, iustin
Attachment:
signature.asc
Description: PGP signature