[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[The good, the bad and] The Ugly -- the cosmetic rant



[For the actual facts, skip the rant, and look at the end of this
mail.]

It happened in the past, and will probably happen in the future, that
I scan incoming for new and interesting packages. When I find
something, the first thing I look at is the packaging (I just love
browsing diffs, really).. Unfortunately, there were times when I had
to quit my $PAGER in disgust, because the packaging sucked so
much. There were times when I contacted the maintainer, and told him
my concerns. Some listened, some did not.

So I told myself, would it be good to scan incoming from time to time,
and harass people? Would it be good to try and do something about
packages, which were done by blindly following some template or
tutorial, without paying much attention? Yes, and that is exactly what
I'll do as frequently as I can.

I'm worried, because I managed to spot quite a few packages done this
way, despite the fact I was just randomly downloading. I'm worried,
because packages whose maintainer didn't pay at least a little
attention to packaging, do not reflect the image I had about
Debian. Sure, Joe Random User will not notice the issues I see. If the
package works for him, it is good. To a prospective developer, or to
anyone who may happen to look at the packaging, it does matter. It
does matter if he sees the skill from the packaging, the care the
maintainer has for his package, or simply a loosely filled out
template..

Don't people see that uploading 3-minute packages do not reflect good
on Debian? Don't they see these packages will paint a bad picture of
them? What would it take to check the diff before upload, to run
lintian on it? It does not cost anything!

One might ask what am I talking about, and why don't I file bugs
against badly done packages instead. The answer to the latter is, that
I can't. The thing that inspired this little rant, is the way some
source packages are done. They work, build, and the binary packages
are as good as can be, yet, when one looks at the diff, it makes him
grin. I do not talk about bugs in software, those will get noticed and
fixed. I do not talk about actual packaging bugs, that makes the
package unbuildable, or does not conform to Policy. Those will be
noticed and fixed. I'm talking about the look of the packaging, the
time that was invested to it, their elegance or the lack of it.

I'm talking about cosmetic issues. Yeah, most people think they are
minor (compared to real bugs, I can agree with that). However, I see
no reason to leave (or introduce) cosmetic problems, when they can be
avoided with a tiny bit of extra effort. The time it takes is nothing,
compared to the time one should spend verifying that his package works
as it should.

Why do I care? It hurts my eyes, and I see many of the issues outlined
below. I do believe it makes us look bad, degrades the quality, if we
don't pay attention even to cosmetic issues. As an example, if you'd
write a book, wouldn't you care about how it would be printed? As
people won't buy even the greatest book if it was printed with
unreadable letters, or if it has TeX markup all over it, they won't
like packages which weren't paid enough attention to.

To get to the actual facts, the issues I saw, analogous to the example
above, lets have a look at an unnamed package, randomly chosen from
the archive!

Quoting from debian/rules:

,----
| configure: configure-stamp
| configure-stamp:
| 	dh_testdir
| 	# Add here commands to configure the package.
| 	./configure --prefix=/usr
| 	touch configure-stamp
`----

There are two issues here. First, the configure-stamp target is
unneeded, configure generates config.status, which can be used as a
stamp file. Second, the comment above the ./configure line - as added
by dh_make, I presume - does not bear any value once the template is
filled out, since you don't have to add anything anymore. Compare this
with TeX markup in a printed book, it's almost the same thing.

The same stands for most of the targets too.

Another bad example is this:

,----
| # Build architecture-independent files here.
| binary-indep: build install
| # We have nothing to do by default.
`----

First, what binary-indep does is documented in the Debian
Policy. Anyone who tries to understand a Debian package should already
be familiar with that document, hence I see no reason to describe what
a required target does (on the other hand, documenting a
hackery-wackery-foo target is a good thing). Furthermore, since it is
an empty target, it is clear that it does not build anything. That can
be probably seen from debian/control too, if it has no Arch: all
packages in it. Yet, one might want to leave a short note in
debian/rules too, that the source does not build any
architecture-independent binaries. In that case, the default comment
should be changed. Why? Consider the sentence: We have nothing to do
by default. It makes me think that there is a way (something which
isn't the default) to build Arch: all packages from this source. As a
dh_make comment, it's appropriate, as a comment in a stand-alone
debian/rules, it is not.

May I ask people to pay a little more attention? Packaging is not a
3-minute thing, it should be Art, a way to show off ones skills.

Thank you.

Attachment: pgp458Kq6wIRH.pgp
Description: PGP signature


Reply to: