web/REJECT-FAQ.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3
   4 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   5 <head>
   6   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
   7   <meta name="description" content="Reject FAQ for Debians NEW Queue" />
   8   <meta name="generator" content="GNU/Emacs" />
   9
  10   <title>Reject FAQ for Debian's NEW-Queue</title>
  11   <link type="text/css" rel="stylesheet" href="style.css" />
  12   <link rel="shortcut icon" href="http://www.debian.org/favicon.ico" />
  13 </head>
  14
  15 <body>
  16   <div class="c1">
  17     <a href="http://www.debian.org/"><img src=
  18     "http://www.debian.org/logos/openlogo-nd-50.png" border="0" hspace="0"
  19     vspace="0" alt="" /></a> <a href="http://www.debian.org/"><img src=
  20     "http://www.debian.org/Pics/debian.png" border="0" hspace="0" vspace=
  21     "0" alt="Debian Project" /></a>
  22   </div><br />
  23
  24   <table class="reddy" width="100%">
  25     <tr>
  26       <td class="reddy"><img src="http://www.debian.org/Pics/red-upperleft.png" align="left" border=
  27       "0" hspace="0" vspace="0" alt="" width="15" height="16" /></td>
  28
  29       <td rowspan="2" class="reddy">Reject FAQ for Debian's NEW-Queue</td>
  30
  31       <td class="reddy"><img src="http://www.debian.org/Pics/red-upperright.png" align="right" border=
  32       "0" hspace="0" vspace="0" alt="" width="16" height="16" /></td>
  33     </tr>
  34
  35     <tr>
  36       <td class="reddy"><img src="http://www.debian.org/Pics/red-lowerleft.png" align="left" border=
  37       "0" hspace="0" vspace="0" alt="" width="16" height="16" /></td>
  38
  39       <td class="reddy"><img src=
  40       "http://www.debian.org/Pics/red-lowerright.png" align="right" border=
  41       "0" hspace="0" vspace="0" alt="" width="15" height="16" /></td>
  42     </tr>
  43   </table>
  44
  45   <h2>Introduction</h2>
  46
  47   <p class="text">NEW checking is about three things. In order of
  48   priority:</p>
  49
  50   <ul>
  51     <li>trying to keep the archive legal,</li>
  52
  53     <li>trying to keep the package namespace sane,</li>
  54
  55     <li>trying to reduce the number of bugs in Debian.</li>
  56   </ul>
  57
  58   <p class="text">Not all QA issues will be noticed; we don't test
  59   packages, but we do look through them and note problems that jump out at
  60   us. Sometimes that'll result in a bug, sometimes it will result in an
  61   email, sometimes it will result in a REJECT, depending on how serious the
  62   issue seems.</p>
  63
  64   <p class="text">Of course this does not take away the developers
  65   responsibility to do their own QA before upload. Its the maintainer who
  66   is responsible for everything that happens with a bad package, not the
  67   ftpteam!</p>
  68
  69   <p class="text">All items are things that <b>really</b> should never
  70   happen anyway, but exist in some packages nonetheless. Visit this list
  71   from time to time, as we may change points or add new ones.</p>
  72
  73   <p class="text">Note: This is a purely informational list, there may be
  74   more reasons. If there is a third column it states the date when the
  75   entry was added to this list.</p>
  76
  77   <p class="text">If you want to make it easy for us, then please state
  78   <b>why</b> you've added a NEW binary package or renamed source. A simple
  79   <i>New upstream</i> or <i>Fixed bug</i> isn't great.</p>
  80
  81   <table border="0">
  82     <tr>
  83       <th class="reject" colspan="3">Serious violations (direct rejects
  84       even if we only find one point)</th>
  85     </tr>
  86
  87     <tr>
  88       <td>OpenSSL</td>
  89
  90       <td>You have a GPL program linking with OpenSSL. This is only ok if
  91       upstream gave a license exception for this otherwise the two licenses
  92       are incompatible. Visit <a href=
  93       "http://www.openssl.org/support/faq.html#LEGAL2">the OpenSSL FAQ</a>
  94       or/and <a href=
  95       "http://www.gnome.org/~markmc/openssl-and-the-gpl.html">another
  96       infotext</a> for more information.</td>
  97
  98       <td>&nbsp;</td>
  99     </tr>
 100
 101     <tr>
 102       <td>CDBS</td>
 103
 104       <td>
 105         You have a cdbs package and for whatever reason turned on the
 106         <i>play with my debian/control in a bad way</i> option. See
 107         <a href="http://bugs.debian.org/311724">#311724</a> for a long text
 108         on that matter.<br />
 109         Small overview: The <i>DEB_AUTO_UPDATE_DEBIAN_CONTROL</i> option
 110         turned on modifies Build-Depends, which doesn't affect the build
 111         that's running. But it affects all following builds, which can be
 112         NMU, buildd builds and worst case: security builds. You <b>DO
 113         NOT</b> want to have such a build getting a different result
 114         (except for the small changes intended with the build) just because
 115         there is now another thing in the build-depends.<br />
 116         Two solutions for this:
 117
 118         <ol>
 119           <li>Think about it and set the Build-Depends yourself. That's
 120           <b>easy</b> and you can check them in pbuilder.</li>
 121
 122           <li>Do this only in a special target in debian/rules that is
 123           NEVER called automagically. So you can check what it did before
 124           you start the real build.</li>
 125         </ol>
 126       </td>
 127
 128       <td>&nbsp;</td>
 129     </tr>
 130
 131     <tr>
 132       <td>PHP License</td>
 133
 134       <td>You have a PHP add-on package (any php script/"app"/thing, not
 135       PHP itself) and its licensed only under the standard PHP license.
 136       That license, up to the 3.x which is actually out, is not really
 137       usable for anything else than PHP itself.
 138           <a href="http://lists.debian.org/debian-legal/2005/08/msg00128.html">I've
 139       mailed</a> our -legal list about that and got only one response,
 140       which basically supported my view on this. Basically this license
 141       talks only about PHP, the PHP Group and <i>includes Zend Engine</i>,
 142       so its not applicable to anything else. And even worse, older
 143       versions include the nice ad-clause.<br />
 144       One good solution here is to suggest a license change to your
 145       upstream, as they clearly wanted a free one. LGPL or BSD seems to be
 146       what they want.</td>
 147
 148       <td>&nbsp;</td>
 149     </tr>
 150
 151     <tr>
 152       <td>License</td>
 153
 154       <td>Be sure that you correctly document the license of the package.
 155       We often find packages having a GPL COPYING file in the source, but
 156       if one goes and looks at every file there are a few here and there
 157       having different licenses in them, sometimes as bad as <i>You aren't
 158       allowed to do anything with this file, and if you do we will send our
 159       lawyers to you</i>. Of course it's hard to check a tarball with
 160       thousands of files (think about X, KDE, Kernel or similar big
 161       packages), but most of the tarballs aren't that big. Also not-nice is
 162       a package, itself being GPL, having documentation licensed with a
 163       non-free license, like the CC licenses. Makes the original tarball
 164       non-free, this is one of the cases where you need to repackage it
 165       (look in the archive for examples, mostly having .dfsg. in their
 166       tarballs name).</td>
 167
 168       <td>&nbsp;</td>
 169     </tr>
 170
 171     <tr>
 172       <td>Transition</td>
 173
 174       <td>You <i>break</i> a transition. Like, in the past we had the
 175                 C++ one, but there might be any number of transitions running.
 176 <!--       Well, right at the moment it's the -->
 177 <!--       nice C++ ABI thing, but in the future it may be something else. For -->
 178 <!--       this C++ one it's basically - if you link against libstdc++5 you are -->
 179 <!--       out, <b>EXCEPT</b> if you declare a special Build-Depends on the -->
 180 <!--       right compiler to get this, which most people haven't done, it's -->
 181 <!--       nearly always not a part of the updated build environment.<br /> -->
 182 <!--       Also having dependencies on non-transitioned C++-libraries gets you -->
 183 <!--       rejected. I think most important libs are done, but until recently a -->
 184 <!--       nice candidate was libqt[whatever]c102. Watch out for c102 names in -->
 185 <!--       your Depends lines if you want to be sure. -->
 186           </td>
 187
 188       <td>&nbsp;</td>
 189     </tr>
 190
 191     <tr>
 192       <td>Experimental Library</td>
 193
 194       <td>Also not good is to build against a version of a library only in
 195       experimental, but uploading to unstable. We may not detect all of
 196       that, but if it happens the package will be rejected.</td>
 197
 198       <td>&nbsp;</td>
 199     </tr>
 200
 201     <tr>
 202       <td>Hijack</td>
 203
 204       <td>You try to hijack a package of an active maintainer ( or team).
 205       Don't do that.</td>
 206
 207       <td>&nbsp;</td>
 208     </tr>
 209
 210     <tr>
 211       <td>Package split</td>
 212
 213       <td>You split a package too much or in a broken way. Well, broken or
 214       too much is a wide definition, so this is a case-by-case thing, but
 215       you should really think about a split before you do it. For example
 216       it doesn't make any sense to split a 50k arch:all package from a 250k
 217       arch:any one. Or splitting a package for only one file, depending on
 218       the main package. Yes, big dependency chains can be a reason. Or big
 219       documentation splitted into one -doc package. The point there is
 220       <b>big</b>.</td>
 221
 222       <td>&nbsp;</td>
 223     </tr>
 224
 225     <tr>
 226       <td>FTBFSIASW</td>
 227
 228       <td>Your package <b>fails to build from source in a sane way</b>. A
 229       good example is behind  <a href="http://bugs.debian.org/300683">#300683</a>,
 230           but I can think of more creative ways to do it. Basically you need be able
 231           to build all .debs with only one call to debian/rules. Not two, not three.
 232           Not an extra script.<br />
 233       This only includes .debs that should get uploaded. Stuff that's only
 234       built by users for their local system doesn't matter.</td>
 235
 236       <td>&nbsp;</td>
 237     </tr>
 238
 239         <tr>
 240           <td>debian/control breakage #2</td>
 241
 242           <td>Your package builds binary packages not listed in
 243                 debian/control.
 244                 While this is technically possible it is not allowed, all
 245                 binaries need to be listed in your control file *prior* to the
 246                 build (ie. that information needs to be included in the uploaded
 247                 source). This mostly happens to kernel-module packages.<br />
 248
 249                 Now, if you follow Policy you have
 250                 <a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles">
 251                 Section 5.2 (Source package control files -- debian/control)</a>
 252                 which says
 253
 254                 <p class="text">
 255                 <cite>The debian/control file contains the most vital (and
 256                 version-independent) information about the source package and
 257                 about the binary packages it creates.<br />
 258
 259                 The first paragraph of the control file contains information
 260                 about the source package in general. The subsequent sets each
 261                 describe a binary package that the source tree builds.
 262                 </cite>
 263                 </p>
 264
 265                 Next location to look is
 266                 <a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles">
 267                 Section 5.4 (Debian source control files -- .dsc)</a> which says
 268
 269                 <p class="text">
 270                 <cite>The source package control file is generated by
 271                 dpkg-source when it builds the source archive, from other files
 272                 in the source package,
 273                 </cite>
 274                 </p>
 275
 276                 which basically means that everything must be defined at the
 277                 beginning of the build.<br/>
 278
 279                 Following the Binary reference we find
 280                 <a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary">
 281                 Section 5.6.19 (Binary)</a> where the important part reads
 282
 283                 <p class="text">
 284                 <cite>
 285                 When it appears in the .dsc file it is the list of binary
 286                 packages which a source package can produce. It does not
 287                 necessarily produce all of these binary packages for every
 288                 architecture. The source control file doesn't contain details of
 289                 which architectures are appropriate for which of the binary
 290                 packages.
 291                 </cite>
 292                 </p>
 293
 294                 Putting all of that together you can simplify it with
 295         <em>debian/control has to contain a list of binaries to be built
 296         <b>before</b> the build-process starts, do not modify that in
 297         the running build-process.</em>
 298
 299         <hr/>
 300
 301         Of course that makes life hard(er) for packages like kernel
 302         modules. But not that much. There is nothing to say against a
 303         target in <i>debian/rules</i> that generates the control file
 304         for you, <b>IFF</b> this is only run manually. And if you run in
 305         troubles with debhelper's -a you may want to read man debhelper(7) for
 306         the -s switch.
 307           </td>
 308
 309           <td>Feb 2006</td>
 310         </tr>
 311     <tr>
 312       <td>Copyright</td>
 313
 314       <td>Your debian/copyright file must have at least the minimum needed
 315       stuff. A good overview of what you need is behind
 316       <a href="http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html">this mail</a>.</td>
 317
 318       <td>&nbsp;</td>
 319     </tr>
 320
 321     <tr>
 322       <td>License II</td>
 323       <td>If the upstream tarball does not include a copy of the license,
 324         debian/copyright must document when and how the license information was
 325         obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from
 326         http://example.net/license" or reproduce email correspondence including
 327         some header) in addition to the reproducing the license itself.
 328       In the past there were uploads where one couldn't
 329       find the license statement in the tarball or on the website from
 330       upstream, which is bad.
 331       </td>
 332       <td>Revised Dec 2008</td>
 333      </tr>
 334     <tr>
 335       <td>License III</td>
 336       <td>You need to list <b>all</b>
 337       copyright information with all licenses in the copyright file itself. That one has
 338       to be the single point of information. Only files you find in /usr/share/common-licenses
 339       have a special exception here, everthing else needs to be fully included!</td>
 340       <td>Revised Dec 2008</td>
 341     </tr>
 342
 343     <tr>
 344       <td>Non-Main</td>
 345
 346       <td>If you want your package in main it must <b>not</b>
 347       (Build-)Depend: or Recommend: a package which isn't in main too.
 348       That's what we have contrib for.</td>
 349
 350       <td>&nbsp;</td>
 351     </tr>
 352
 353     <tr>
 354       <td>Package Content</td>
 355
 356       <td>You most probably want to have some content in your package. From
 357       time to time we find packages which don't have any. An example is a
 358       rename of a lib* package, but to miss updating the place where the
 359       files are installed.</td>
 360
 361       <td>&nbsp;</td>
 362     </tr>
 363
 364     <tr>
 365       <td>Policy Violation</td>
 366
 367       <td>It should really not violate policy, for example violating FHS.
 368       Like installing libFOO.so in /usr/share, creating random new
 369       /pathentries or any other obvious policy violation.</td>
 370
 371       <td>&nbsp;</td>
 372     </tr>
 373
 374     <tr>
 375       <td>Contents of orig.tar.gz</td>
 376
 377       <td>If you rebuild the orig.tar.gz (in the few cases this is needed,
 378       most of the times it is NOT) - be sure to not include .so/.a/other
 379       compiled files. You should also exclude
 380       .cvs/.svn/.whatever_your_version_control_system_has directories you
 381       added.</td>
 382
 383       <td>&nbsp;</td>
 384     </tr>
 385
 386     <tr>
 387       <td>Lintian</td>
 388
 389       <td>Lintian errors and warnings, without a good reason to ignore them
 390       can get you a reject. Sometimes there are valid reasons, but then you
 391       should either file a bug against lintian if it's generally wrong or
 392       include an override in your package, giving a reason in the changelog
 393       for it.</td>
 394
 395       <td>&nbsp;</td>
 396     </tr>
 397
 398     <tr>
 399       <td>rpath</td>
 400
 401       <td>Watch out if you include a rpath in your binaries. Most of the
 402       time this is not what you want but it is easy to fix. See
 403           <a href="http://wiki.debian.org/RpathIssue">this Wiki</a> for
 404       more.</td>
 405
 406       <td>&nbsp;</td>
 407     </tr>
 408
 409     <tr>
 410       <td>Package name</td>
 411
 412       <td>Use the right package names. A lib should start with lib, a perl
 413       module with lib and end with -perl, etc.</td>
 414
 415       <td>&nbsp;</td>
 416     </tr>
 417
 418     <tr>
 419       <td>Common license</td>
 420
 421       <td>Do not include a license that is in /usr/share/common-licenses
 422       into your debian/copyright. That's a waste of space.</td>
 423
 424       <td>&nbsp;</td>
 425     </tr>
 426
 427     <tr>
 428       <td>Renaming source for DFSG-removals</td>
 429
 430       <td>Do not rename the source if you delete files that are not DFSG free.
 431       Instead add a .dfsg. somewhere to the version part to mark it. Renaming the source
 432       just confuses tools like the PTS who are source-package based, and also confuses
 433       users who cant simply fetch sources anymore without looking what source package
 434       it is first.
 435       </td>
 436
 437       <td>June 2006</td>
 438     </tr>
 439
 440         <tr>
 441           <td>Wrong license pointer</td>
 442
 443           <td>Be careful at what file in /usr/share/common-licenses you
 444                 point. (L)GPL is <b>only</b> correct if the licensing allows you
 445                 to chose "or any later" version. If it does not and you have a
 446                 licensing that does not give you that option you have to use the
 447                 versioned file (L)GPL-2 or -3.</td>
 448           <td>Januar 2008</td>
 449         </tr>
 450
 451         <tr>
 452           <td>Symbol file wrong</td>
 453
 454           <td>Your symbol file contains errors, as reported from lintian
 455                 with the two tags
 456                 <i>symbols-file-contains-current-version-with-debian-revision</i>
 457                 and <i>symbols-file-contains-debian-revision</i>.
 458           </td>
 459           <td>Januar 2008</td>
 460         </tr>
 461         <tr>
 462           <td>Source missing</td>
 463           <td>Your packages contains files that need source
 464               but do not have it. These include PDF and PS files in the documentation.</td>
 465           <td>December 2008</td>
 466         </tr>
 467   </table><br />
 468   <br />
 469
 470   <table border="0">
 471     <tr>
 472       <th class="reject" colspan="3">Minor issues, sometimes also named
 473       "Good packaging behavior". Not a single one is enough to get you a
 474       REJECT, but if you collect multiple ones the probability rises:</th>
 475     </tr>
 476
 477     <tr>
 478       <td>Description</td>
 479
 480       <td>Have a good description for your package. Both short and long.
 481       You should know what your package does but your users don't. So write
 482       something that they know what they get <b>before</b> they install it.
 483       A simple <b>XY, it does stuff</b> is nothing that should get
 484       uploaded.</td>
 485
 486       <td>August 2005</td>
 487     </tr>
 488
 489     <tr>
 490       <td>Repackage orig.tar.gz</td>
 491
 492       <td>Do not repackage your orig.tar.gz unless you have to. If you need
 493       to remove files due to license issues - OK. But for example to have
 494       the directory in the tarball named pkgname-ver you DO NOT repackage.
 495       dpkg-source completely doesn't care about that.</td>
 496
 497       <td>August 2005</td>
 498     </tr>
 499
 500     <tr>
 501       <td>Native/Non-Native</td>
 502
 503       <td>Be sure to look for native/non-native build. Its easy to build a
 504       package native because you had a spelling error in the upstream
 505       tarballs name. Simple solution: Whenever you have a -X in your
 506       version number (ie a debian-revision) look if you have a .diff.gz
 507       before you upload.</td>
 508
 509       <td>August 2005</td>
 510     </tr>
 511
 512     <tr>
 513       <td>Multiple versions</td>
 514
 515       <td>Do not add the third version of a lib/program. Get RID of them
 516       instead. Always try to not have more than two version of a
 517       library/program in, and that also only if its needed due to a hard
 518       transition to the newer one.</td>
 519
 520       <td>August 2005</td>
 521     </tr>
 522
 523     <tr>
 524       <td>debian/rules</td>
 525
 526       <td>Have a clear debian/rules file. A bad example are the dh-make
 527       templates. As the name says: they are templates. Edit them, test your
 528       package and then delete the whole bunch of commands that are
 529       commented out, make it hard to read and do not help. If you later
 530       need anything: Type dh_[TAB][TAB] to see whats available.</td>
 531
 532       <td>August 2005</td>
 533     </tr>
 534
 535     <tr>
 536       <td>.ex files</td>
 537
 538       <td>Remove the .ex files from debian/. They are examples not meant to
 539       stay around.</td>
 540
 541       <td>August 2005</td>
 542     </tr>
 543
 544     <tr>
 545       <td>Standards-Version</td>
 546
 547       <td>Standards-Version should be the latest available one, not any
 548       ancient that may happen to get in with a template you use.</td>
 549
 550       <td>August 2005</td>
 551     </tr>
 552
 553     <tr>
 554       <td>Manpages</td>
 555
 556       <td>Write manpages. Yes. Really. Write them. Well. It's basically: If
 557       your program/tool has a --help and --version commandline option you
 558       can simply run
 559           <a href="http://packages.debian.org/help2man">help2man</a> and have a working
 560       start. Such easy ones are near to a reject. Yes, there are things in
 561       the archive where its hard to write manpages.</td>
 562
 563       <td>August 2005</td>
 564     </tr>
 565
 566     <tr>
 567       <td>Useless Settings</td>
 568
 569       <td>Having a "INSTALL_PROGRAM += -s" setting if nostrip option is set
 570       while using dh_strip later. Useless, read man dh_strip please. There
 571       may be other things like this, this is just a prominent example. If
 572       they are there - remove them please.</td>
 573
 574       <td>August 2005</td>
 575     </tr>
 576   </table>
 577
 578   <p class="validate"><!-- hhmts start -->Last modified: Sat Dec 13 15:58:41 UTC 2008 <!-- hhmts end --></p>
 579   <hr />
 580   <a href="http://validator.w3.org/check?uri=referer">
 581   <img border="0" src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0 Transitional"
 582        height="31" width="88" /></a>
 583   <a href="http://jigsaw.w3.org/css-validator/check/referer">
 584   <img border="0" src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"
 585        height="31" width="88" /></a>
 586 </body>
 587 </html>