Re: Nitpicking: you are doing it wrong
On Saturday, July 09, 2011 12:41:09 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).
+ a debhelperized use pattern, for performing common tasks, is very likely to
be way more robust than a 200 lines of (self-tested) NIH thing, simply because
thousand of people using/testing it. It is about re-use of well tested code, a
lot of wisdom has been accumulated and implanted during the years.
+ If we were to live with the old concepts and old patterns, which might have
been valid a decade ago, then there would be no progress and inventions at
all. Debhelper is the perfect compromise (as design) and a giant step upward
(as implementation).
> Cheers
>
> [0] http://en.wikipedia.org/wiki/Not_Invented_Here
> [1] [🔎] 4E176B0D.8060100@debian.org">http://lists.debian.org/msgid-search/[🔎] 4E176B0D.8060100@debian.org
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: