I better put my biases up front. I'm the dh-make author. I'm also one of AMs who has processed the most appicants so I see a lot of them (noone beats tbm though).
On Fri, Oct 12, 2001 at 06:43:08PM +0200, Gergely Nagy wrote: > Nowadays, in times of the autotools, dh_make and debhelper, packaging > software (here, and throughout this e-mail, I'm talking about the > typical package an average applicant usually selects, mostly > autotools-based, or some perl/python/whatever scripts) is rather > easy. I could even say it's too trivial. I want to elaborate on this > `too' thing. I would like to describe what I would like to see, and > contrast it with reality. And yet this is exactly the sort of package that they will most likely find and for a long while the most likely package that they will maintain. This helper versus bare-bone thread comes up every now and then. I cannot really see much advantage on forcing people down that path. User's are not going to thank you for it. > This includes that the debian/rules script should not include > unnecessary targets, only those that are actually used and/or mandated > by Policy. Reality strikes here first: dh_make's templates were > probably made for a hypothetic autotools-based package, the typical > ./configure && make && make install one. Thus, it has a configure > target, which is very useful, if it's actually used, but useless junk > otherwise. As I see it, some people don't care about this, and leave > it there, with the ./configure part commented out, even for packages > that do not, and probably never will use the auto* suite. The same > goes for the docbook-to-man command. Actually it looks for configure and if it finds it it uses that. The dh-make templates actually derive from debhelper examples. > Another common problem is when people modify the upstream Makefile, > even when it's unnecessary. For example, I've seen packages which add > this line to the Makefile: I do agree with this, you should try to minimise the amount of changes you do to the makefile, unless it is incredibly broken which distressingly happens all too often. > Not to mention what I recently saw in a package (*shrug*): the dh_make > template includes $(MAKE) in the build-stamp target, however, the > package in question was a set of perl scripts, and the only target in > the Makefile was `install'. I would have thought that every sane > person would remove $(MAKE) from the build-stamp target. Furthermore, > the whole build-stamp target, as only a `build: ;' (ie, an empty > target) would be enough. Alas, it turned out that I was too > optimistic: an `all' target was patched into the Makefile, which only > echoed that there's nothing to build. This sort of thing shouldn't happen, but really does it matter? I would consider this a minor bug. OK its not elegant, but does the package build? Yes, it would. Does it introduce bugs? No it doesn't. So it's not the end of the world. > I know that my problems are small, mostly cosmetic things. However, I > believe that Debian packages should be done elegantly, even if that > means some extra work, even if it means that removing those > commented-out debhelper commands, which are not used now, but might > be, in some later point (they should be added back then, not left > around until such times come). This WOULD introduce bugs. Some debhelper things need to be done in a certain order or they don't work, don't work properly. You're "purism" is going to lead to more not less bugs. > properly). To make this happen as soon as possible, I would even > strengthen the rules for applying, by requiring a debhelper-less > package ready (of course, with exceptions, like porters). Those who > can do it, or are willing to learn and spend a few hours looking at > documentation and/or searching for samples, will do this > easily. Those, who are incapable of doing so, should not apply at all. For what purpose, so people can say "i can make a package without debhelper"? Really! is there any other reason for it? - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/ <[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
