Greetings!
As some may know, I ask my applicants to do a package without
debhelper, so I can be sure, that they know what goes on behind the
scenes. There were cases where the first tries weren't good. In fact,
they were bad. And that made me wonder..
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.
The first thing I try to enforce is that the packaging should be
simple, clean and elegant. Unnecessary code and files should be
eliminated.
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.
It happens often that debian/rules is filled with a number of empty
lines, which makes it slightly harder to see what belongs together.
The other common thing I see in debian/rules, is that the dh_make
comments (like `# We have nothing to do by default.'), which are
unnecessary, and probably only there for the maintainer to see what he
should put there, and what that particular target is used for. Then,
there are the commented-out debhelper commands. Why are they there, if
they're not used? They just make the diff larger, and serve no other
purpose.
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:
DESTDIR=
That just doesn't make sense. Another typical crap is this:
-FOODIR=/usr/lib/bar
+FOODIR=${DESTDIR}/usr/lib/bar
Spend two lines of diff, plus context, plus header, just to change one
tiny thing, which could be set from debian/rules, on the make command
line.
Don't get me wrong, if the workarounds would be worse than changing
upstream sources, then of course the source should be changed.
Those who dare to touch upstream sources without need, tend to fall
deeper into that pit. As an example, when there's no install target in
the original Makefile, they patch it. Even if it would be an `install
-m 0755 foo debian/foo/usr/bin/bar' line in debian/rules' install
target. No, they go and patch the Makefile instead, introducing a
great deal of junk into the diff.
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.
For now, I'll keep the other bits for myself. However, I'd like to ask
the Applicant Managers to be anal about the packages, and don't accept
trivial ones, for that defeats the purpose of the Skills check.
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).
I sincerely hope that this trend will stop, and even our applicants
will spend some time learning the basics of packaging, and not just
try to blindly follow a template (which is good and useful, when used
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.
Thanks for listening.
--
Gergely Nagy \ mhp/|8]
(P.S.: These are my ramblings, as an applicant manager. They have
nothing to do with the Front Desk)
Attachment:
pgpSHSFXA4RvP.pgp
Description: PGP signature