Re: Nitpicking: you are doing it wrong
On 09/07/11 13:53, Thomas Goirand wrote:
> If you are writing that using dh is more easy than using "normal" debhelper,
> then I don't agree, it's not always the case. I've seen many overly
> complicated
> packages with tons of dh_overwrite_* stuff, which makes the work flow very
> complicated and barely readable.
You're missing the point again: of course you can make dh rules
unreadable. The point is that it's easier to write *more* readable rules
*most* of the time. Mind you: nobody ever said *always*.
It's like Joey Hess mentioned in another mail in the thread: when used
correctly, the override targets make it clearer where the package
actually needed special treatment, which means I don't have to look for
the proverbial needle in the haystack when reading a potentially big
rules file; it's already explicitly there for me to see.
> I'm not bying into the legend that a dh using package is more easy to
> maintain.
Legend? Maybe I'm reading too much into it, but it really sounds like
you have an emotional grudge against dh.
But we seem to be discussing two different and unrelated things here:
1) maintainability
2) understanding of the underlying system
I say they're unrelated because it's irrelevant to the first point if
the maintainer knows how a tool works as long as he knows how to use it
to overcome possible problems and the end-package quality remains the same.
I'll address the first point here and the second as a response a bit
further down.
What makes a package easier to maintain must be judged by the ease with
which a different DD can make contributions to it, because the
maintainer him/herself is way too used to the code to make objective
observations (you probably remember why you used this or that, so it
shouldn't seem complex to you). I also assume that starting from
scratch, without any prejudice, it's *at least* as easy to learn to use
dh_* helpers as dh short style (again: we're discussing just the first
point here; no understanding necessary at this point).
Now, all things being equal you want to do an NMU. If it's your average
package with just one important but small detail, you might very well
open the rules file, parse its ~100 lines, not see the detail, try to
make whatever change you wanted to make, have it blow up in your face
and finally go back to the rules file and read it more carefully.
Why did you miss the detail? Because it's easier to miss something in
~100 lines of almost-always-identical code (where you skim more then
read), than in 10 lines of code where the only thing is an override
target telling you *exactly* what you should pay attention to.
To make matters a bit worse, dh_* style encourages a bit of cruft: since
the lines have to be there anyway, you have less incentive to clean up
after yourself and remove arguments which aren't needed anymore (like
old -X arguments for files that aren't installed anymore). This may not
have any impact on the final package, but it adds up to the things
people unfamiliar with the code will try to keep in mind, even if it's
unimportant, making the job of understanding the rules file a bit harder.
Of course these arguments highlight a *small* difference in
maintainability and are in no way reason for me to go out screaming for
people to re-upload everything with dh short style, but it's reason
enough for a so inclined sponsor to ask potential sponsorees "please use
a shorter rules file where possible because I don't want to have to
parse ~100 lines of almost-standard dh_* example code to make sure I'm
not doing something stupid whenever I want to change something"
> As for the performance, it's quite obvious that dh is doing so many useless
> debhelper calls. Just read what you see on screen.
Yes, that's obvious, but does it cost you more than a couple of seconds
per build? No.
In that case, these mere seconds are more then worth it making a more
readable package for your average DD. (again, I can't stress it enough:
I'm not saying it's a "one size fits all" solution, but use it where it
works).
You make it sound like these extra dh_ calls have some impact besides
irritating you on a pure "quest for theoretical elegance" level, which
they don't.
> I hope you didn't miss-read me. I do push for using debhelper, but not dh,
> which I have reasons to dislike. One of the most obvious reason is that
> people
> are going to just rely on things they don't understand. It's hiding a
> complexity
> that people HAVE to understand. CDBS is even worth than dh in this regard.
And here I address the second point mentioned earlier.
This argument is also a dud. It's equally easy for a maintainer to use
dh_* or dh short style without knowing what's going on underneath. I
know I did this with dh_* almost 10 years ago. You can simply copy one
of the example dh-make rules files and semi-blindly hack away at it
until it compiles and generates a lintian-clean package. You don't
automatically gain more knowledge about the system simply because you
copied a template with more code in it.
But by the time the package compiled, you hopefully learned a bit about
how these tools work and fit together, because fixing build-bugs is the
best way to stimulate learning. And this can be said for *both* ways of
using debhelper - or any other helper, for that matter.
Bottom line is: unless you're writing your rules file completely by hand
(which would be very inefective - to say the least - for all but the
most pathological cases) you're always relying on something you probably
don't understand completely and making rules files more explicit, while
still using wrappers and helpers, has no direct effect on this. It only
makes for more text to parse.
Cheers
--
Leo "costela" Antunes
[insert a witty retort here]
Reply to: