Re: The Helper Rant
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/ <csmall@eye-net.com.au>
MIEEE <csmall@ieee.org> Debian developer <csmall@debian.org>
Reply to: