[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