Fun with the NEW queue

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