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] http://lists.debian.org/msgid-search/[email protected] -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
