Thomas Goirand <z...@debian.org> writes: >> On Fri, Jul 08, 2011 at 12:55 +0200, Jakub Wilk wrote: >> >> [...] but should be made explicit as the reasons not to use dh, for >> example, might mean that the helper is lacking functionality or >> behaves buggy in certain situations. > > I don't get it here... > > Do you think that debian/rules calling the emacs debhelper > when it's not needed 99.9999% of the times is a superior way > to do packaging? Or is using something fully automated where > you don't have to think or understand what's going on a better > way to do things? > > In what way not using dh has to be justified at all? I'd rather say > the opposite way! I really don't think that dh is "state-of-the-art" > (as Arno is saying later on in this thread).
As someone who was very strongly against helpers in the past[0], please allow me to chime in. I do agree that whoever is packaging a piece of software needs to understand how the system works underneath. However, once that is understood, I now see no harm in using dh: I know what it will be doing, and that extra ~5 seconds spent calling helpers that do nothing is something I couldn't care less about. I much more prefer a ~6 line debian/rules, that works now, and thanks to the helpers, will very likely work a year from now, without me having to change it, because the helpers will adapt the package to current policy. One still needs to verify that the result is what one expects, but it's much easier to verify, than to migrate AND verify aswell. We have tools to serve us, let the tools do that! Or we can go out and build debs with tar and ar. (I actually had an applicant in the past who suprised me with a package that did just that. ;) Personally, I find dh to be very neat, and useful, as it allows me to keep my rules very short. Comparing my current packages to the ones I made a decade ago, the new ones are much easier to understand and update. I recently had a look at an old package of mine.. it was a mess. Two pages of gory, uninteresting, perfectly common commands instead of two lines of this: %: dh $@ I believe that when someone knows the underlying system, using helpers is the way to go, because it makes not only your task easier, it also makes it easier for others to understand the packaging. NMUing something with a complex, home-built debian/rules is a pain in the backside at best. And yes, one does sacrifice a lot of control on the altar of convenience. But I don't see that as a problem, there's nothing wrong with convenience. And while useless helper scripts add to the build time, that load is negligible. Even on the slowest machine I could get my hands on (emulated armel, with ~256Mb memory, running on an dual-core amd64 host, along with 4 other VMs), the difference between using dh $@ and explicit dh_* commands on an average package was about 3 seconds. Completely getting rid of debhelper and doing everything by hand made it 2 more seconds faster. I don't know about you, but for 5 seconds, I'm not going to give up convenience. There's also the case where the assumptions made by the helper tools work against the packager's wishes, and at that point, when the tools start to get in one's way, they should be either fixed, or dropped. When the effort spent on workarounds start to approach the time saved by the tools, it's time to reevaluate, and perhaps drop the helpers. But until then, why? Then again, the beauty of Debian is that people are allowed to tailor their packaging to their own liking (as long as it conforms to policy... sadly a debian/rules written in SHOOP does not). There's arguments for and against both helper-using and helper-less packaging, neither is a silver bullet. 0: http://lists.debian.org/debian-newmaint/2001/10/msg00021.html -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739iglbjm....@luthien.mhp