Re: Nitpicking: you are doing it wrong
On 07/09/2011 05:41 AM, Leo "costela" Antunes wrote:
> On 08/07/11 22:23, Thomas Goirand wrote:
>
>> On 07/08/2011 08:47 PM, Scott Howard wrote:
>>
>>> Right now, the general consensus is the dh and cdbs produce
>>> debian packages that are easier to maintain in the long run (if the
>>> sponsor has to take over maintenance of the package or if NMUs are
>>> required in the future.)
>>>
>> I really would like you to explain WHERE you saw such a consensus.
>> When it goes down to myself, I would *not* sponsor a package that
>> is using either dh or CDBS, because I like to be in the control and see
>> what's going on. I believe that CDBS/dh is hiding what's necessary to
>> do a good packaging, and is calling too many unnecessary helpers,
>> which slows down the build process. Also, with dh_override_*, if you
>> have a lot of them, it soon becomes unreadable. That's only my opinion
>> though, but I suspect that I might not be the only one to think this way.
>> In anyways, I don't see at all a consensus here!!!
>>
> Seeing what's going on is important for learning and for debugging.
> Thankfully debugging with dh is pretty mature, should you happen to need
> it (don't really know about cdbs), but having to read a non-dh-using
> rules file to understand exactly what happens when and why can be a lot
> of work and shouldn't be imposed on your fellow DDs if you don't have a
> good reason for it (curiosity and a micro-management tendency are not
> good reasons; funky non-standard build-systems are)
>
> Please use dh/cdbs/whatever other means necessary to make your packaging
> work easy to read and understand. Don't make the packaging more complex
> for other people just because you want to "know what's going on". That
> sounds awfully like NIH[0].
> You never know who might have to NMU it, make QA uploads, etc and even
> you yourself might find it pretty hard to remember why you did something
> in this particular fashion, when it actually could just as well be done
> in a more common way.
> Not using these tools goes against your own advice here[1]: you're
> making the life of other developers who have to look at your code harder
> for no reason.
> Or to put it more succinctly in your own words: "otherwise, you have no
> rules at all and it's a mess".
>
> And your performance argument seems like a dud unless you can provide
> some evidence that you actually save a significant amount of time by not
> using dh/cdbs/whatever during package builds (and by significant I mean
> more than just a couple of seconds per build).
>
> Cheers
>
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.
I'm not bying into the legend that a dh using package is more easy to
maintain.
As for the performance, it's quite obvious that dh is doing so many useless
debhelper calls. Just read what you see on screen.
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.
On 07/09/2011 07:09 PM, Bernhard R. Link wrote:
> But please also do not use anything you do not understand.
> I my eyes the normal dh_* scripts are a good middle ground in being
> high level enough to not hide the big picture in details while still
> being transparent enough to know what's going on. Especially having
> the calls to upstream's build system in such files explicitly listed
> makes it easy to check they are called the proper way.
> Using dh or cdbs means it needs quite some knowledge to be sure it
> is done right.
Exactly!!! And while I'm not pushing you to like or use this type of
packaging,
I don't see why you should push me for another one.
Thomas
Reply to: