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 -- 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/4e18414d.70...@debian.org
