Bundling up a few replies here... On Sat, Jun 10, 2006 at 10:02:26AM +0300, George Danchev wrote: > I'm also debhelper fan ;-) but what makes you think that if you face a > problematic debhelper script you are not supposed to reimplement that > particular part of rules by hand as an interim workaround ? I don't think I implied that it wouldn't be appropriate to do this -- actually, my point is precisely that there's a big gap in the *difficulty* of doing this for debhelper vs. cdbs. For debhelper, you delete one line and replace it with a very small shell script. For cdbs, you delete one line and have to replace it with your reimplementation of a very large makefile... On Sat, Jun 10, 2006 at 10:39:32AM +0200, Thomas Weber wrote: > first off, I'm neither a DD nor an NM, but I do some packaging work > (thanks to alioth), As most people here argue against CDBS, I think the > benefits of it are missed (if you didn't guess, I use it and I like it). Oh, I disagree; I think I have a pretty good idea what the benefits are of CDBS, I just think that many CDBS proponents underemphasize the *downside* of CDBS. > Am Freitag, den 09.06.2006, 15:10 -0700 schrieb Steve Langasek: > > On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote: > > > > This is also my impression. CDBS might be nice to automate the task > > > > "make a .deb out of this Gnome source", but imho it completely fails > > > > when you want to deviate from the "standard" in any way. > I guess this paragraph sums it up pretty good. CDBS is not the best > choice if you need something *not* _c_ommon. OTOH, if I see a CDBS > based rules files with three lines, this tells me one thing pretty > clearly: there's nothing unusual in this package. So tell me, how do you know a priori whether the software you're packaging is going to be "common", or if it's going to need to deviate from CDBS at some point in the future? If you're recommending a packaging style to a new packager who probably doesn't have the level of committment to learn more than a single helper style, how do you know whether they will at some point need to package something that doesn't fit in cdbs's neat little view of the world? > > Let's compare debhelper to cdbs. > I don't quite agree with your analysis. If you say "CDBS stuff is > under /usr/share/cdbs", you must as well say "dh_* stuff is > under /usr/share/perl5/Debian/Debhelper/". I was pointing out that you can't learn anything about what cdbs does by looking at the debian/rules of a package that uses it. If I have a debian/rules file that invokes a command, and I don't understand what that command does, I can look at the manpage. If I have a debian/rules file that includes other makefiles, my choices are to look at the include file itself and study it (for which the *shortest* of these is as long as the stock dh-make template rules file), or track down the cdbs documentation... which in at least one noteworthy case tells me to go look at the include files anyway (hee). I dunno, maybe my work habits mean I'm missing out on some great IDE features that make it non-painful to track through makefile includes, but for me, about the second time I find myself typing /usr/share/ to look at a file in order to understand what a package is doing, I start to get a little grumpy about it. :) > The problem is the documentation, which leaves room for improvement. I > mean, how many people would understand dh_* without the manpages? Er... is that really meant to be a defense of CDBS? debhelper *does* have manpages, and this is an important part of why I think it's better. > I mean, if I want default values for a program, I do "./configure" and > not "./configure --enable-default-prefix --enable-default-docpath ..." Hmm, interesting comparison, given all the arguments that cdbs itself passes to ./configure by default: --build=$(DEB_BUILD_GNU_TYPE) --prefix=$(DEB_CONFIGURE_PREFIX) \ --includedir=$(DEB_CONFIGURE_INCLUDEDIR) \ --mandir=$(DEB_CONFIGURE_MANDIR) --infodir=$(DEB_CONFIGURE_INFODIR) \ --sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR) \ --localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR) \ --libexecdir=$(DEB_CONFIGURE_LIBEXECDIR) --disable-maintainer-mode \ --disable-dependency-tracking :) On Sat, Jun 10, 2006 at 11:08:15AM +0200, Loïc Minier wrote: > You are looking at the individual dh_* commands, but: > - the precise list of debhelper calls varies from package to package, > there's nothing standard or documented in this > - the order of the debhelper calls varies from package to package What problems does this cause? I mean, I've heard of a few bugs from time to time caused by maintainers putting key debhelper commands out of order; but I've seen the same sort of thing happen to cdbs-using packages too, and I don't see that having such slight variations in debian/rules files seriously harming comprehension. > Compare with CDBS where the list of debhelper calls has some order > constraints and where the list itself can evolve: introduction of > dh_gconf in the rules used by GNOME packages is only a matter of adding > the call to the relevant CDBS file, not to each individual package. The flip side of this is that the behavior of cdbs-using packages is always changing, without the knowledge or control of the package maintainer. E.g., while I was drafting this message, <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372273;msg=10> showed up in my mailbox... > I agree that it's a nice feature to be able to say dh_install conforms > to its documentation, yet the same feature is available in CDBS which > calls dh_install: the precise dh_install call will happen from CDBS > instead of directly from your debian/rules, but you have the same > documentation, and interface to write your debian/*.install files. But I, as a package maintainer, can't actually depend on the dh_install interface if I use cdbs because *I'm* not using dh_install. My interface is "include /usr/share/cdbs/1/rules/debhelper.mk", for which no specific behavior is defined -- the behavior is simply "do whatever debhelper-related packaging operations that the maintainers of cdbs thought was appropriate when this version of cdbs was packaged", and as we see, this has definitely changed over time. > Agreed, documentation is a bit lacking and could be improved. More > importantly, the interface is not as clearly defined as a command call, > because Makefiles allow much more. I can't imagine what to put in a > simple-patchsys.mk man page, or it would be as long as the original > makefile. No, clearly makefile includes shouldn't have manpages; but some kind of documentation that tells cdbs users what they should or shouldn't be able to depend on would be a good idea. In the absence of such documentation I think the current answer to what they can depend on is actually "very little", which is a big part of why I don't encourage its use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature