Re: Nitpicking: you are doing it wrong
Thomas Goirand <zigo@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]
Reply to: