--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+ <meta name="description" content="Reject FAQ for Debians NEW Queue" />
+ <meta name="generator" content="GNU/Emacs" />
+
+ <title>Reject FAQ for Debian's NEW-Queue</title>
+ <link type="text/css" rel="stylesheet" href="style.css" />
+ <link rel="shortcut icon" href="http://www.debian.org/favicon.ico" />
+</head>
+
+<body>
+ <div class="c1">
+ <a href="http://www.debian.org/"><img src=
+ "http://www.debian.org/logos/openlogo-nd-50.png" border="0" hspace="0"
+ vspace="0" alt="" /></a> <a href="http://www.debian.org/"><img src=
+ "http://www.debian.org/Pics/debian.png" border="0" hspace="0" vspace=
+ "0" alt="Debian Project" /></a>
+ </div><br />
+
+ <table class="reddy" width="100%">
+ <tr>
+ <td class="reddy"><img src="http://www.debian.org/Pics/red-upperleft.png" align="left" border=
+ "0" hspace="0" vspace="0" alt="" width="15" height="16" /></td>
+
+ <td rowspan="2" class="reddy">Reject FAQ for Debian's NEW-Queue</td>
+
+ <td class="reddy"><img src="http://www.debian.org/Pics/red-upperright.png" align="right" border=
+ "0" hspace="0" vspace="0" alt="" width="16" height="16" /></td>
+ </tr>
+
+ <tr>
+ <td class="reddy"><img src="http://www.debian.org/Pics/red-lowerleft.png" align="left" border=
+ "0" hspace="0" vspace="0" alt="" width="16" height="16" /></td>
+
+ <td class="reddy"><img src=
+ "http://www.debian.org/Pics/red-lowerright.png" align="right" border=
+ "0" hspace="0" vspace="0" alt="" width="15" height="16" /></td>
+ </tr>
+ </table>
+
+ <h2>Introduction</h2>
+
+ <p class="text">NEW checking is about three things. In order of
+ priority:</p>
+
+ <ul>
+ <li>trying to keep the archive legal,</li>
+
+ <li>trying to keep the package namespace sane,</li>
+
+ <li>trying to reduce the number of bugs in Debian.</li>
+ </ul>
+
+ <p class="text">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.</p>
+
+ <p class="text">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!</p>
+
+ <p class="text">All items are things that <b>really</b> should never
+ happen anyway, but exist in some packages nonetheless. Visit this list
+ from time to time, as we may change points or add new ones.</p>
+
+ <p class="text">Note: This is a purely informational list, there may be
+ more reasons. If there is a third column it states the date when the
+ entry was added to this list.</p>
+
+ <p class="text">If you want to make it easy for us, then please state
+ <b>why</b> you've added a NEW binary package or renamed source. A simple
+ <i>New upstream</i> or <i>Fixed bug</i> isn't great.</p>
+
+ <table border="0">
+ <tr>
+ <th class="reject" colspan="3">Serious violations (direct rejects
+ even if we only find one point)</th>
+ </tr>
+
+ <tr>
+ <td>OpenSSL</td>
+
+ <td>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 <a href=
+ "http://www.openssl.org/support/faq.html#LEGAL2">the OpenSSL FAQ</a>
+ or/and <a href=
+ "http://www.gnome.org/~markmc/openssl-and-the-gpl.html">another
+ infotext</a> for more information.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>CDBS</td>
+
+ <td>
+ You have a cdbs package and for whatever reason turned on the
+ <i>play with my debian/control in a bad way</i> option. See
+ <a href="http://bugs.debian.org/311724">#311724</a> for a long text
+ on that matter.<br />
+ Small overview: The <i>DEB_AUTO_UPDATE_DEBIAN_CONTROL</i> option
+ turned on modifies Build-Depends, which doesn't affect the build
+ that's running. But it affects all following builds, which can be
+ NMU, buildd builds and worst case: security builds. You <b>DO
+ NOT</b> 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.<br />
+ Two solutions for this:
+
+ <ol>
+ <li>Think about it and set the Build-Depends yourself. That's
+ <b>easy</b> and you can check them in pbuilder.</li>
+
+ <li>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.</li>
+ </ol>
+ </td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>PHP License</td>
+
+ <td>You have a PHP add-on 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, is not really
+ usable for anything else than PHP itself.
+ <a href="http://lists.debian.org/debian-legal/2005/08/msg00128.html">I've
+ mailed</a> 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 <i>includes Zend Engine</i>,
+ so its not applicable to anything else. And even worse, older
+ versions include the nice ad-clause.<br />
+ 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.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>License</td>
+
+ <td>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 bad as <i>You aren't
+ allowed to do anything with this file, and if you do we will send our
+ lawyers to you</i>. 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).</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Transition</td>
+
+ <td>You <i>break</i> a transition. Like, in the past we had the
+ C++ one, but there might be any number of transitions running.
+<!-- Well, right at the moment it's 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, <b>EXCEPT</b> if you declare a special Build-Depends on the -->
+<!-- right compiler to get this, which most people haven't done, it's -->
+<!-- nearly always not a part of the updated build environment.<br /> -->
+<!-- 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 for c102 names in -->
+<!-- your Depends lines if you want to be sure. -->
+ </td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Experimental Library</td>
+
+ <td>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.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Hijack</td>
+
+ <td>You try to hijack a package of an active maintainer ( or team).
+ Don't do that.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Package split</td>
+
+ <td>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
+ <b>big</b>.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>FTBFSIASW</td>
+
+ <td>Your package <b>fails to build from source in a sane way</b>. A
+ good example is behind <a href="http://bugs.debian.org/300683">#300683</a>,
+ but I can think of more creative ways to do it. Basically you need be able
+ to build all .debs with only one call to debian/rules. Not two, not three.
+ Not an extra script.<br />
+ This only includes .debs that should get uploaded. Stuff that's only
+ built by users for their local system doesn't matter.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>debian/control breakage #2</td>
+
+ <td>Your package builds binary packages not listed in
+ debian/control.
+ While this is technically possible it is not allowed, all
+ binaries need to be listed in your control file *prior* to the
+ build (ie. that information needs to be included in the uploaded
+ source). This mostly happens to kernel-module packages.<br />
+
+ Now, if you follow Policy you have
+ <a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles">
+ Section 5.2 (Source package control files -- debian/control)</a>
+ which says
+
+ <p class="text">
+ <cite>The debian/control file contains the most vital (and
+ version-independent) information about the source package and
+ about the binary packages it creates.<br />
+
+ The first paragraph of the control file contains information
+ about the source package in general. The subsequent sets each
+ describe a binary package that the source tree builds.
+ </cite>
+ </p>
+
+ Next location to look is
+ <a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles">
+ Section 5.4 (Debian source control files -- .dsc)</a> which says
+
+ <p class="text">
+ <cite>The source package control file is generated by
+ dpkg-source when it builds the source archive, from other files
+ in the source package,
+ </cite>
+ </p>
+
+ which basically means that everything must be defined at the
+ beginning of the build.<br/>
+
+ Following the Binary reference we find
+ <a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary">
+ Section 5.6.19 (Binary)</a> where the important part reads
+
+ <p class="text">
+ <cite>
+ When it appears in the .dsc file it is the list of binary
+ packages which a source package can produce. It does not
+ necessarily produce all of these binary packages for every
+ architecture. The source control file doesn't contain details of
+ which architectures are appropriate for which of the binary
+ packages.
+ </cite>
+ </p>
+
+ Putting all of that together you can simplify it with
+ <em>debian/control has to contain a list of binaries to be built
+ <b>before</b> the build-process starts, do not modify that in
+ the running build-process.</em>
+
+ <hr/>
+
+ Of course that makes life hard(er) for packages like kernel
+ modules. But not that much. There is nothing to say against a
+ target in <i>debian/rules</i> that generates the control file
+ for you, <b>IFF</b> this is only run manually. And if you run in
+ troubles with debhelper's -a you may want to read man debhelper(7) for
+ the -s switch.
+ </td>
+
+ <td>Feb 2006</td>
+ </tr>
+ <tr>
+ <td>Copyright</td>
+
+ <td>Your debian/copyright file must have at least the minimum needed
+ stuff. A good overview of what you need is behind
+ <a href="http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html">this mail</a>.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>License II</td>
+ <td>If the upstream tarball does not include a copy of the license,
+ debian/copyright must document when and how the license information was
+ obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from
+ http://example.net/license" or reproduce email correspondence including
+ some header) in addition to the reproducing the license itself.
+ In the past there were uploads where one couldn't
+ find the license statement in the tarball or on the website from
+ upstream, which is bad.
+ </td>
+ <td>Revised Dec 2008</td>
+ </tr>
+ <tr>
+ <td>License III</td>
+ <td>You need to list <b>all</b>
+ copyright information with all licenses in the copyright file itself. That one has
+ to be the single point of information. Only files you find in /usr/share/common-licenses
+ have a special exception here, everthing else needs to be fully included!</td>
+ <td>Revised Dec 2008</td>
+ </tr>
+
+ <tr>
+ <td>Non-Main</td>
+
+ <td>If you want your package in main it must <b>not</b>
+ (Build-)Depend: or Recommend: a package which isn't in main too.
+ That's what we have contrib for.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Package Content</td>
+
+ <td>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.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Policy Violation</td>
+
+ <td>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.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Contents of orig.tar.gz</td>
+
+ <td>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.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Lintian</td>
+
+ <td>Lintian errors and warnings, without a good reason to ignore them
+ can get you 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.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>rpath</td>
+
+ <td>Watch out if you include a rpath in your binaries. Most of the
+ time this is not what you want but it is easy to fix. See
+ <a href="http://wiki.debian.org/RpathIssue">this Wiki</a> for
+ more.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Package name</td>
+
+ <td>Use the right package names. A lib should start with lib, a perl
+ module with lib and end with -perl, etc.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Common license</td>
+
+ <td>Do not include a license that is in /usr/share/common-licenses
+ into your debian/copyright. That's a waste of space.</td>
+
+ <td> </td>
+ </tr>
+
+ <tr>
+ <td>Renaming source for DFSG-removals</td>
+
+ <td>Do not rename the source if you delete files that are not DFSG free.
+ Instead add a .dfsg. somewhere to the version part to mark it. Renaming the source
+ just confuses tools like the PTS who are source-package based, and also confuses
+ users who cant simply fetch sources anymore without looking what source package
+ it is first.
+ </td>
+
+ <td>June 2006</td>
+ </tr>
+
+ <tr>
+ <td>Wrong license pointer</td>
+
+ <td>Be careful at what file in /usr/share/common-licenses you
+ point. (L)GPL is <b>only</b> correct if the licensing allows you
+ to chose "or any later" version. If it does not and you have a
+ licensing that does not give you that option you have to use the
+ versioned file (L)GPL-2 or -3.</td>
+ <td>Januar 2008</td>
+ </tr>
+
+ <tr>
+ <td>Symbol file wrong</td>
+
+ <td>Your symbol file contains errors, as reported from lintian
+ with the two tags
+ <i>symbols-file-contains-current-version-with-debian-revision</i>
+ and <i>symbols-file-contains-debian-revision</i>.
+ </td>
+ <td>Januar 2008</td>
+ </tr>
+ <tr>
+ <td>Source missing</td>
+ <td>Your packages contains files that need source
+ but do not have it. These include PDF and PS files in the documentation.</td>
+ <td>December 2008</td>
+ </tr>
+ </table><br />
+ <br />
+
+ <table border="0">
+ <tr>
+ <th class="reject" colspan="3">Minor issues, sometimes also named
+ "Good packaging behavior". Not a single one is enough to get you a
+ REJECT, but if you collect multiple ones the probability rises:</th>
+ </tr>
+
+ <tr>
+ <td>Description</td>
+
+ <td>Have a good description for your package. Both short and long.
+ You should know what your package does but your users don't. So write
+ something that they know what they get <b>before</b> they install it.
+ A simple <b>XY, it does stuff</b> is nothing that should get
+ uploaded.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>Repackage orig.tar.gz</td>
+
+ <td>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 completely doesn't care about that.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>Native/Non-Native</td>
+
+ <td>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.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>Multiple versions</td>
+
+ <td>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 its needed due to a hard
+ transition to the newer one.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>debian/rules</td>
+
+ <td>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 whats available.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>.ex files</td>
+
+ <td>Remove the .ex files from debian/. They are examples not meant to
+ stay around.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>Standards-Version</td>
+
+ <td>Standards-Version should be the latest available one, not any
+ ancient that may happen to get in with a template you use.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>Manpages</td>
+
+ <td>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
+ <a href="http://packages.debian.org/help2man">help2man</a> 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.</td>
+
+ <td>August 2005</td>
+ </tr>
+
+ <tr>
+ <td>Useless Settings</td>
+
+ <td>Having a "INSTALL_PROGRAM += -s" setting if nostrip option is set
+ while using dh_strip later. Useless, read man dh_strip please. There
+ may be other things like this, this is just a prominent example. If
+ they are there - remove them please.</td>
+
+ <td>August 2005</td>
+ </tr>
+ </table>
+
+ <p class="validate"><!-- hhmts start -->Last modified: Sat Dec 13 15:58:41 UTC 2008 <!-- hhmts end --></p>
+ <hr />
+ <a href="http://validator.w3.org/check?uri=referer">
+ <img border="0" src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0 Transitional"
+ height="31" width="88" /></a>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer">
+ <img border="0" src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"
+ height="31" width="88" /></a>
+</body>
+</html>
projects / dak.git / blobdiff