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] -- 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/iv9oln$1k5$1...@dough.gmane.org
