Hi
As you may have noticed, the beloved target of many flamewars, the
NEW queue [1] has been reduced to an average of less than 10
packages. Packages are processed within days, sometimes even within
hours.
In order to slow it right back down again, so you dont get used to it
too much, I decided to become insane and do even more. I plan
to add some very rough quality checks - nothing should surprise you, but
all of these problems were already seen in the queue. Not everything that
makes a package RC-buggy is listed, but will also count as a reason
for a reject - iff we notice it.
Of course this does not take away the developers responsibility to do
their own QA before upload. Its the maintainer who is responsible for
everything that happens with a bad package, not the ftpteam!
NEW checking is about three things. In order of priority: trying to keep the
archive legal, trying to keep the package namespace sane, and trying to
reduce the number of bugs in Debian.
Not all QA issues will be noticed; we don't test packages, but we do look
through them and note problems that jump out at us. Sometimes that'll
result in a bug, sometimes it will result in an email, sometimes it will
result in a REJECT, depending on how serious the issue seems.
To avoid flames from surprised maintainers, I have decided to post a little
list of things we look for, so you can fix your packages before uploading.
All items are things that *really* should never happen anyway, but
exist in some packages nonetheless. You can find this list at
http://ftp-master.debian.org/REJECT-FAQ.html in the future and that one will also
be updated if we need to.
This is purely an informational list and is from the top of my
head. There may be more reasons. I mark reasons added with this mail
with a star, so you can quickly see what's new. Most of the added points
are just quality issues.
While I'm at it: If you want to make it easy for us, then please state
*why* you've added a NEW binary package or renamed source. A simple
"New upstream" or "Fixed bug" isn't great.
Serious violations (direct rejects even if we only find one point):
- You have a GPL program linking with OpenSSL.
This is only ok if upstream gave a license exception for this otherwise
the two licenses are incompatible.
Visit http://www.openssl.org/support/faq.html#LEGAL2 or/and
http://www.gnome.org/~markmc/openssl-and-the-gpl.html for more
information.
- You have a cdbs package and for whatever reason turned on the "play
with my debian/control in a bad way" option. See #311724 for a long
text on that matter.
Small overview is in Footnote [2].
- You have a PHP addon package (any php script/"app"/thing, not PHP
itself) and its licensed only under the standard PHP license. That
license, up to the 3.x which is actually out[3], is not really usable
for anything else than PHP itself. I've mailed[4] our -legal list
about that and got only one response, which basically supported my
view on this. Basically this license talks only about PHP, the PHP
Group and "includes Zend Engine", so its not applicable to anything
else. And even worse, older versions include the nice ad-clause.
One good solution here is to suggest a license change to your
upstream, as they clearly wanted a free one. LGPL or BSD seems to be
what they want.
- Be sure that you correctly document the license of the package.
We often find packages having a GPL COPYING file in the source, but if one
goes and looks at every file there are a few here and there having
different licenses in them, sometimes as bas as "You aren't
allowed to do anything with this file, and if you do we will send our
lawyers to you". Of course it's hard to check a tarball with thousands
of files (think about X, KDE, Kernel or similar big packages), but most of
the tarballs aren't that big.
Also not-nice is a package, itself being GPL, having documentation licensed
with a non-free license, like the CC licenses. Makes the original
tarball non-free, this is one of the cases where you need to repackage
it (look in the archive for examples, mostly having .dfsg. in their
tarballs name).
- You "break" a transition. Well, right at the moment its the nice C++
ABI thing, but in the future it may be something else. For this C++ one
it's basically - if you link against libstdc++5 you are out, *EXCEPT*
if you declare a special Build-Depends on the right compiler to get
this which most people havent done and its nearly always not part of the
build environment.
Also having dependencies on non-transitioned C++-libraries gets you
rejected. I think most important libs are done, but until recently a nice
candidate was libqt[whatever]c102. Watch out c102 names in your
Depends lines if you want to be sure.
- Also not good is to build against a version of a library only in
experimental, but uploading to unstable. We may not detect all of that,
but if it happens the package will be rejected. :)
- You try to hijack a package of an active maintainer (or team). Don't do
that.
- You split a package too much or in a broken way. Well,
broken or too much is a wide definition, so this is a case-by-case
thing, but you should really think about a split before you do it.
For example it doesn't make any sense to split a 50k arch:all package
from a 250k arch:any one. Or splitting a package for only one file,
depending on the main package.
Yes, big dependency chains can be a reason. Or big documentation splitted
into one -doc package. The point there is *big* :)
- Your package "fails to build from source in a sane way". A good
example is behind #300683, but I can think of more creative ways to do
it. Basically you need to be able to build all[5] .debs with only one call to
debian/rules. Not two, not three. Not an extra script.
- Your debian/copyright file must have at least the minimum needed
stuff. A good overview of what you need is in the thread starting at
http://lists.debian.org/debian-legal/2003/12/msg00188.html
- Your upstream tarball needs to include a copy of the license, or
debian/copyright needs to explain where it can be found. (eg. the upstream
website). In the past there were uploads where one couldnt find the
license statement in the tarball or on the website from upstream,
which is bad.
- Do not include a license that is in /usr/share/common-licenses into
your debian/copyright. That's a waste of space.
- If the license is not in /usr/share/common-licenses it must be copied
verbatim into debian/copyright, a pointer to the package or a website
is not enough.
- If you want your package in main it must *not* (Build-)Depend: or Recommend:
a package which isn't in main too. Thats what we have contrib for.
- You most probably want to have some content in your package. From time to
time we find packages which don't have any. An example is a rename of a
lib* package, but to miss updating the place where the files are installed.
- It should really not violate policy, for example violating FHS. Like
installing libFOO.so in /usr/share, creating random new /pathentries
or any other obvious policy violation.
- If you rebuild the orig.tar.gz (in the few cases this is needed, most
of the times it is NOT) - be sure to not include .so/.a/other compiled
files. You should also exclude .cvs/.svn/.whatever_your_version_control_system_has
directories you added.
- Lintian errors and warnings, without a good reason to ignore them can
get your package a reject. Sometimes there are valid reasons, but then you should either
file a bug against lintian if it's generally wrong or include an override
in your package, giving a reason in the changelog for it.
- Watch out if you include a rpath in your binaries. Most of the time
this is not what you want but it's easy to fix.
See http://wiki.debian.net/index.cgi?RpathIssue for more details.
- Use the right package names. A lib should start with lib, a perl
module with lib and end with -perl, etc.
Minor issues, sometimes also named "Good packaging behaviour". Not a single
one is enough to get you a REJECT, but if you collect multiple ones the probability
rises:
* Have a good description for your package. Both short and long.
You should know what you packager does but your users don't. So write
something that they will understand *before* they install it.
A simple "XY, it does stuff" is not something that should get uploaded.
* Do not repackage your orig.tar.gz unless you have to. If you need to
remove files due to license issues - OK. But for example to have the
directory in the tarball named pkgname-ver you DO NOT
repackage. dpkg-source completly doesn't care for that.
* Be sure to look for native/non-native build. Its easy to build a
package native because you had a spelling error in the upstream
tarballs name. Simple solution: Whenever you have a -X in your version
number (ie a debian-revision) look if you have a .diff.gz before you
upload.
* Do not add the third version of a lib/program. Get RID of them
instead. Always try to not have more than two version of a
library/program in, and that also only if it's needed due to the hard
transition to a newer one.
* Write manpages. Yes. Really. Write them.
Well. It's basically: If your program/tool has a --help and --version
commandline option you can simply run help2man and have a working
start. Such easy ones are near to a reject.
Yes, there are things in the archive where its hard to write
manpages.
* Have a clear debian/rules file. A bad example are the dh-make
templates. As the name says: they are templates. Edit them, test your
package and then delete the whole bunch of commands that are commented
out, make it hard to read and do not help. If you later need anything:
Type dh_[TAB][TAB] to see what's available.
* Remove the .ex files from debian/. They are examples and not meant to
stay around.
* Standards-Version should be the latest available one, not any ancient
that may happen to get in with a template you use.
* Having a "INSTALL_PROGRAM += -s" setting if nostrip option is set
while using dh_strip later. Useless, read man dh_strip please. :)
[1] http://ftp-master.debian.org/new.html
[2] The "DEB_AUTO_UPDATE_DEBIAN_CONTROL" option turned on modifies
Build-Depends, which doesnt affect the build thats running. But it
affects all following builds, which can be NMU, buildd builds and worst
case: security builds. You *DO NOT* want to have such a build getting a
different result (except for the small changes intended with the build)
just because there is now another thing in the build-depends.
Two solutions for this: a.) Think about it and set the Build- Depends
yourself. Thats *easy* and you can check them in pbuilder. b.) Do this
only in a special target in debian/rules that is NEVER called
automagically. So you can check what it did before you start the real
build.
[3] But many people still use older ones, like 2.xx.
[4] http://lists.debian.org/debian-legal/2005/08/msg00128.html
[5] This only includes .debs that should get uploaded. Stuff that's only
built by users for their local system doesn't matter.
--
bye Joerg
I think there's a world market for about five computers.
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
Attachment:
pgp7euYqyf3aC.pgp
Description: PGP signature