]> git.decadent.org.uk Git - dak.git/blob - web/REJECT-FAQ.html
Merge remote branch 'stew/contents' into merge
[dak.git] / 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>