/[ddp]/manuals/trunk/developers-reference/pkgs.dbk
ViewVC logotype

Diff of /manuals/trunk/developers-reference/pkgs.dbk

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 7314 by taffit-guest, Thu May 6 01:04:08 2010 UTC revision 8539 by taffit-guest, Thu Mar 3 03:16:36 2011 UTC
# Line 55  the rejection email in case you are alre Line 55  the rejection email in case you are alre
55  </para>  </para>
56  <para>  <para>
57  When closing security bugs include CVE numbers as well as the  When closing security bugs include CVE numbers as well as the
58  <literal>Closes: #<replaceable>nnnnn</replaceable></literal>  <literal>Closes: #<replaceable>nnnnn</replaceable></literal>.
59  This is useful for the security team to track vulnerabilities.  If an upload is  This is useful for the security team to track vulnerabilities.  If an upload is
60  made to fix the bug before the advisory ID is known, it is encouraged to modify  made to fix the bug before the advisory ID is known, it is encouraged to modify
61  the historical changelog entry with the next upload.  Even in this case, please  the historical changelog entry with the next upload.  Even in this case, please
# Line 135  It is conventional that the changelog en Line 135  It is conventional that the changelog en
135  upstream version of the software looks like this:  upstream version of the software looks like this:
136  </para>  </para>
137  <screen>  <screen>
138    * new upstream version    * New upstream release.
139  </screen>  </screen>
140  <para>  <para>
141  There are tools to help you create entries and finalize the  There are tools to help you create entries and finalize the
# Line 174  output a very verbose description of the Line 174  output a very verbose description of the
174  </para>  </para>
175  <para>  <para>
176  Normally, a package should <emphasis>not</emphasis> be uploaded if it causes  Normally, a package should <emphasis>not</emphasis> be uploaded if it causes
177  lintian to emit errors (they will start with <literal>E</literal>).  <command>lintian</command> to emit errors (they will start with <literal>E</literal>).
178  </para>  </para>
179  <para>  <para>
180  For more information on <command>lintian</command>, see <xref  For more information on <command>lintian</command>, see <xref
# Line 230  accompanied by another file that contain Line 230  accompanied by another file that contain
230  </itemizedlist>  </itemizedlist>
231  <para>  <para>
232  For the native packages, the source package includes a Debian source control  For the native packages, the source package includes a Debian source control
233  file (<literal>.dsc</literal>) and the source tarball  file (<filename>.dsc</filename>) and the source tarball
234  (<literal>.tar.{gz,bz2,lzma}</literal>). A source package of a non-native package  (<filename>.tar.{gz,bz2,lzma}</filename>). A source package of a non-native package
235  includes a Debian source control file, the original source tarball  includes a Debian source control file, the original source tarball
236  (<literal>.orig.tar.{gz,bz2,lzma}</literal>) and the Debian changes  (<filename>.orig.tar.{gz,bz2,lzma}</filename>) and the Debian changes
237  (<literal>.diff.gz</literal> for the source format “1.0” or  (<filename>.diff.gz</filename> for the source format “1.0” or
238  <literal>.debian.tar.{gz,bz2,lzma}</literal> for the source format “3.0 (quilt)”).  <filename>.debian.tar.{gz,bz2,lzma}</filename> for the source format “3.0 (quilt)”).
239  </para>  </para>
240  <para>  <para>
241  With source format “1.0”, whether a package is native or not was determined  With source format “1.0”, whether a package is native or not was determined
# Line 268  the archive. Line 268  the archive.
268  </para>  </para>
269  <para>  <para>
270  Please notice that, in non-native packages, permissions on files that are not  Please notice that, in non-native packages, permissions on files that are not
271  present in the .orig.tar.{gz,bz2,lzma} will not be preserved, as diff does not store file  present in the <filename>*.orig.tar.{gz,bz2,lzma}</filename> will not be preserved, as diff does not store file
272  permissions in the patch. However when using source format “3.0 (quilt)”,  permissions in the patch. However when using source format “3.0 (quilt)”,
273  permissions of files inside the <filename>debian</filename> directory are  permissions of files inside the <filename>debian</filename> directory are
274  preserved since they are stored in a tar archive.  preserved since they are stored in a tar archive.
# Line 862  The nature of the fix, if any is availab Line 862  The nature of the fix, if any is availab
862  <listitem>  <listitem>
863  <para>  <para>
864  Any fixed packages that you have prepared yourself (send only the  Any fixed packages that you have prepared yourself (send only the
865  <literal>.diff.gz</literal> and <literal>.dsc</literal> files and read <xref  <filename>.diff.gz</filename> and <filename>.dsc</filename> files and read <xref
866  linkend="bug-security-building"/> first)  linkend="bug-security-building"/> first)
867  </para>  </para>
868  </listitem>  </listitem>
# Line 962  be sure to mention this fact. Line 962  be sure to mention this fact.
962  <para>  <para>
963  Please note that if secrecy is needed you may not upload a fix to  Please note that if secrecy is needed you may not upload a fix to
964  <literal>unstable</literal> (or  <literal>unstable</literal> (or
965  anywhere else, such as a public CVS repository).  It is not sufficient to  anywhere else, such as a public VCS repository).  It is not sufficient to
966  obfuscate the details of the change, as the code itself is public, and can (and  obfuscate the details of the change, as the code itself is public, and can (and
967  will) be examined by the general public.  will) be examined by the general public.
968  </para>  </para>
# Line 1278  short summary of the reason for the remo Line 1278  short summary of the reason for the remo
1278  <replaceable>[architecture list]</replaceable> is optional and only needed  <replaceable>[architecture list]</replaceable> is optional and only needed
1279  if the removal request only applies to some architectures, not all. Note  if the removal request only applies to some architectures, not all. Note
1280  that the <command>reportbug</command> will create a title conforming  that the <command>reportbug</command> will create a title conforming
1281  to these rules when you use it to report a bug against the <literal>  to these rules when you use it to report a bug against the
1282  ftp.debian.org</literal> pseudo-package.  <literal>ftp.debian.org</literal> pseudo-package.
1283  </para>  </para>
1284    
1285  <para>  <para>
# Line 1292  pending removal requests. Line 1292  pending removal requests.
1292  </para>  </para>
1293    
1294  <para>  <para>
1295  Note that removals can only be done for the <literal>unstable  Note that removals can only be done for the <literal>unstable</literal>,
1296  </literal>, <literal>experimental</literal> and <literal>stable  <literal>experimental</literal> and <literal>stable</literal>
1297  </literal> distribution.  Packages are not removed from  distribution.  Packages are not removed from
1298  <literal>testing</literal> directly.  Rather, they will be removed  <literal>testing</literal> directly.  Rather, they will be removed
1299  automatically after the package has been removed from  automatically after the package has been removed from
1300  <literal>unstable</literal> and no package in <literal>testing  <literal>unstable</literal> and no package in
1301  </literal> depends on it.  <literal>testing</literal> depends on it.
1302  </para>  </para>
1303  <para>  <para>
1304  There is one exception when an explicit removal request is not necessary: If a  There is one exception when an explicit removal request is not necessary: If a
# Line 1337  the <command>apt-cache</command> program Line 1337  the <command>apt-cache</command> program
1337  role="package">apt</systemitem> package.  When invoked as <literal>apt-cache  role="package">apt</systemitem> package.  When invoked as <literal>apt-cache
1338  showpkg <replaceable>package</replaceable></literal>, the program will show  showpkg <replaceable>package</replaceable></literal>, the program will show
1339  details for <replaceable>package</replaceable>, including reverse depends.  details for <replaceable>package</replaceable>, including reverse depends.
1340  Other useful programs include <literal>apt-cache rdepends</literal>,  Other useful programs include <command>apt-cache rdepends</command>,
1341  <command>apt-rdepends</command>, <command>build-rdeps</command> (in the  <command>apt-rdepends</command>, <command>build-rdeps</command> (in the
1342  <systemitem role="package">devscripts</systemitem> package) and  <systemitem role="package">devscripts</systemitem> package) and
1343  <command>grep-dctrl</command>.  Removal of  <command>grep-dctrl</command>.  Removal of
# Line 1379  rename their software (or you made a mis Line 1379  rename their software (or you made a mis
1379  you should follow a two-step process to rename it. In the first  you should follow a two-step process to rename it. In the first
1380  step, change the <filename>debian/control</filename> file to  step, change the <filename>debian/control</filename> file to
1381  reflect the new name and to replace, provide and conflict with the  reflect the new name and to replace, provide and conflict with the
1382  obsolete package name (see the <ulink url="&url-debian-policy;">  obsolete package name (see the <ulink url="&url-debian-policy;">Debian
1383  Debian Policy Manual</ulink> for details).  Please note that you  Policy Manual</ulink> for details).  Please note that you
1384  should only add a <literal>Provides</literal> relation if all  should only add a <literal>Provides</literal> relation if all
1385  packages depending on the obsolete package name continue to work  packages depending on the obsolete package name continue to work
1386  after the renaming. Once you've uploaded the package and the package  after the renaming. Once you've uploaded the package and the package
1387  has moved into the archive, file a bug against <literal>  has moved into the archive, file a bug against <literal>ftp.debian.org</literal>
1388  ftp.debian.org</literal> asking to remove the package with the  asking to remove the package with the
1389  obsolete name (see <xref linkend="removing-pkgs"/>).  Do not forget  obsolete name (see <xref linkend="removing-pkgs"/>).  Do not forget
1390  to properly reassign the package's bugs at the same time.  to properly reassign the package's bugs at the same time.
1391  </para>  </para>
# Line 1464  more information). Line 1464  more information).
1464  If you take over an old package, you probably want to be listed as the  If you take over an old package, you probably want to be listed as the
1465  package's official maintainer in the bug system.  This will happen  package's official maintainer in the bug system.  This will happen
1466  automatically once you upload a new version with an updated  automatically once you upload a new version with an updated
1467  <literal>Maintainer:</literal> field, although it can take a few hours after  <literal>Maintainer</literal> field, although it can take a few hours after
1468  the upload is done.  If you do not expect to upload a new version for a while,  the upload is done.  If you do not expect to upload a new version for a while,
1469  you can use <xref linkend="pkg-tracking-system"/> to get the bug reports.  you can use <xref linkend="pkg-tracking-system"/> to get the bug reports.
1470  However, make sure that the old maintainer has no problem with the fact that  However, make sure that the old maintainer has no problem with the fact that
# Line 1487  Porting is the act of building Debian pa Line 1487  Porting is the act of building Debian pa
1487  different from the original architecture of the package maintainer's binary  different from the original architecture of the package maintainer's binary
1488  package.  It is a unique and essential activity.  In fact, porters do most of  package.  It is a unique and essential activity.  In fact, porters do most of
1489  the actual compiling of Debian packages.  For instance, when a maintainer  the actual compiling of Debian packages.  For instance, when a maintainer
1490  uploads a (portable) source packages with binaries for the <literal>i386  uploads a (portable) source packages with binaries for the <literal>i386</literal>
1491  </literal> architecture, it will be built for each of the other architectures,  architecture, it will be built for each of the other architectures,
1492  amounting to &number-of-arches; more builds.  amounting to &number-of-arches; more builds.
1493  </para>  </para>
1494  <section id="kind-to-porters">  <section id="kind-to-porters">
# Line 1592  standardize on different compilers. Line 1592  standardize on different compilers.
1592  </listitem>  </listitem>
1593  <listitem>  <listitem>
1594  <para>  <para>
1595  Make sure your debian/rules contains separate <literal>binary-arch</literal>  Make sure your <filename>debian/rules</filename> contains separate <literal>binary-arch</literal>
1596  and <literal>binary-indep</literal> targets, as the Debian Policy Manual  and <literal>binary-indep</literal> targets, as the Debian Policy Manual
1597  requires.  Make sure that both targets work independently, that is, that you  requires.  Make sure that both targets work independently, that is, that you
1598  can call the target without having called the other before.  To test this,  can call the target without having called the other before.  To test this,
# Line 1623  The way to invoke <command>dpkg-buildpac Line 1623  The way to invoke <command>dpkg-buildpac
1623  -m<replaceable>porter-email</replaceable></literal>.  Of course, set  -m<replaceable>porter-email</replaceable></literal>.  Of course, set
1624  <replaceable>porter-email</replaceable> to your email address.  This will do a  <replaceable>porter-email</replaceable> to your email address.  This will do a
1625  binary-only build of only the architecture-dependent portions of the package,  binary-only build of only the architecture-dependent portions of the package,
1626  using the <literal>binary-arch</literal> target in <filename>debian/rules  using the <literal>binary-arch</literal> target in
1627  </filename>.  <filename>debian/rules</filename>.
1628  </para>  </para>
1629  <para>  <para>
1630  If you are working on a Debian machine for your porting efforts and you need to  If you are working on a Debian machine for your porting efforts and you need to
# Line 1648  version number greater than the currentl Line 1648  version number greater than the currentl
1648  You have to make sure that your binary-only NMU doesn't render the package  You have to make sure that your binary-only NMU doesn't render the package
1649  uninstallable.  This could happen when a source package generates  uninstallable.  This could happen when a source package generates
1650  arch-dependent and arch-independent packages that have inter-dependencies  arch-dependent and arch-independent packages that have inter-dependencies
1651  generated using dpkg's substitution variable <literal>$(Source-Version)  generated using dpkg's substitution variable <literal>$(Source-Version)</literal>.
 </literal>.  
1652  </para>  </para>
1653  <para>  <para>
1654  Despite the required modification of the changelog, these are called  Despite the required modification of the changelog, these are called
# Line 1665  source code). Line 1664  source code).
1664  </para>  </para>
1665  <para>  <para>
1666  The ``magic'' for a recompilation-only NMU is triggered by using a suffix  The ``magic'' for a recompilation-only NMU is triggered by using a suffix
1667  appended to the package version number, following the form <literal>  appended to the package version number, following the form
1668  b<replaceable>number</replaceable></literal>.  <literal>b<replaceable>number</replaceable></literal>.
1669  For instance, if the latest version you are recompiling against was version  For instance, if the latest version you are recompiling against was version
1670  <literal>2.9-3</literal>, your binary-only NMU should carry a version of  <literal>2.9-3</literal>, your binary-only NMU should carry a version of
1671  <literal>2.9-3+b1</literal>.  If the latest version was <literal>3.4+b1  <literal>2.9-3+b1</literal>.  If the latest version was <literal>3.4+b1</literal>
1672  </literal> (i.e, a native package with a previous recompilation NMU), your  (i.e, a native package with a previous recompilation NMU), your
1673  binary-only NMU should have a version number of <literal>3.4+b2</literal>.  binary-only NMU should have a version number of <literal>3.4+b2</literal>.<footnote><para>
1674  <footnote><para> In the past, such NMUs used the third-level number on the  In the past, such NMUs used the third-level number on the
1675  Debian part of the revision to denote their recompilation-only status;  Debian part of the revision to denote their recompilation-only status;
1676  however, this syntax was ambiguous with native packages and did not allow  however, this syntax was ambiguous with native packages and did not allow
1677  proper ordering of recompile-only NMUs, source NMUs, and security NMUs on  proper ordering of recompile-only NMUs, source NMUs, and security NMUs on
# Line 1690  to only build the architecture-dependent Line 1689  to only build the architecture-dependent
1689  <title>When to do a source NMU if you are a porter</title>  <title>When to do a source NMU if you are a porter</title>
1690  <para>  <para>
1691  Porters doing a source NMU generally follow the guidelines found in <xref  Porters doing a source NMU generally follow the guidelines found in <xref
1692  linkend="nmu"/> , just like non-porters.  However, it is expected that the wait  linkend="nmu"/>, just like non-porters.  However, it is expected that the wait
1693  cycle for a porter's source NMU is smaller than for a non-porter, since porters  cycle for a porter's source NMU is smaller than for a non-porter, since porters
1694  have to cope with a large quantity of packages.  Again, the situation varies  have to cope with a large quantity of packages.  Again, the situation varies
1695  depending on the distribution they are uploading to.  It also varies whether  depending on the distribution they are uploading to.  It also varies whether
# Line 1706  on the <literal>unstable</literal> distr Line 1705  on the <literal>unstable</literal> distr
1705  if the problem is critical and imposes hardship on the porting effort, at the  if the problem is critical and imposes hardship on the porting effort, at the
1706  discretion of the porter group.  (Remember, none of this is Policy, just  discretion of the porter group.  (Remember, none of this is Policy, just
1707  mutually agreed upon guidelines.) For uploads to <literal>stable</literal> or  mutually agreed upon guidelines.) For uploads to <literal>stable</literal> or
1708  <literal>testing </literal>, please coordinate with the appropriate release  <literal>testing</literal>, please coordinate with the appropriate release
1709  team first.  team first.
1710  </para>  </para>
1711  <para>  <para>
# Line 1769  linkend="tools-porting"/>. Line 1768  linkend="tools-porting"/>.
1768  <para>  <para>
1769  The <systemitem role="package">wanna-build</systemitem> system is used as a  The <systemitem role="package">wanna-build</systemitem> system is used as a
1770  distributed, client-server build distribution system.  It is usually used in  distributed, client-server build distribution system.  It is usually used in
1771  conjunction with build daemons running the <systemitem role="package">buildd  conjunction with build daemons running the <systemitem role="package">buildd</systemitem>
1772  </systemitem> program. <literal>Build daemons</literal> are ``slave'' hosts  program. <literal>Build daemons</literal> are ``slave'' hosts
1773  which contact the central <systemitem role="package"> wanna-build</systemitem>  which contact the central <systemitem role="package">wanna-build</systemitem>
1774  system to receive a list of packages that need to be built.  system to receive a list of packages that need to be built.
1775  </para>  </para>
1776  <para>  <para>
# Line 1784  version is not the same as the one used Line 1783  version is not the same as the one used
1783  enough to reproduce problems.  enough to reproduce problems.
1784  </para>  </para>
1785  <para>  <para>
1786  Most of the data produced by <systemitem role="package">wanna-build  Most of the data produced by <systemitem role="package">wanna-build</systemitem>
1787  </systemitem> which is generally useful to porters is available on the  which is generally useful to porters is available on the
1788  web at <ulink url="&url-buildd;"></ulink>.  This data includes nightly  web at <ulink url="&url-buildd;"></ulink>.  This data includes nightly
1789  updated statistics, queueing information and logs for build attempts.  updated statistics, queueing information and logs for build attempts.
1790  </para>  </para>
# Line 1845  fail also, and indicate this to a human Line 1844  fail also, and indicate this to a human
1844  <listitem>  <listitem>
1845  <para>  <para>
1846  In order to prevent autobuilders from needlessly trying to build your package,  In order to prevent autobuilders from needlessly trying to build your package,
1847  it must be included in <filename>packages-arch-specific</filename>, a list used  it must be included in <filename>Packages-arch-specific</filename>, a list used
1848  by the <command>wanna-build</command> script.  The current version is available  by the <command>wanna-build</command> script.  The current version is available
1849  as <ulink url="&url-buildd-p-a-s;"/>;  as <ulink url="&url-buildd-p-a-s;"/>;
1850  please see the top of the file for whom to contact for changes.  please see the top of the file for whom to contact for changes.
# Line 1854  please see the top of the file for whom Line 1853  please see the top of the file for whom
1853  </itemizedlist>  </itemizedlist>
1854  <para>  <para>
1855  Please note that it is insufficient to only add your package to  Please note that it is insufficient to only add your package to
1856  Packages-arch-specific without making it fail to build on unsupported  <filename>Packages-arch-specific</filename> without making it fail to build on unsupported
1857  architectures: A porter or any other person trying to build your package might  architectures: A porter or any other person trying to build your package might
1858  accidently upload it without noticing it doesn't work.  If in the past some  accidently upload it without noticing it doesn't work.  If in the past some
1859  binary packages were uploaded on unsupported architectures, request their  binary packages were uploaded on unsupported architectures, request their
1860  removal by filing a bug against <systemitem  removal by filing a bug against <systemitem
1861  role="package">ftp.debian.org</systemitem>  role="package">ftp.debian.org</systemitem>.
1862  </para>  </para>
1863  </section>  </section>
1864    
# Line 1928  is given an opportunity to upload a fix Line 1927  is given an opportunity to upload a fix
1927  When doing an NMU, you must first make sure that your intention to NMU is  When doing an NMU, you must first make sure that your intention to NMU is
1928  clear.  Then, you must send a patch with the differences between the  clear.  Then, you must send a patch with the differences between the
1929  current package and your proposed NMU to the BTS. The  current package and your proposed NMU to the BTS. The
1930  <literal>nmudiff</literal> script in the <literal>devscripts</literal> package  <command>nmudiff</command> script in the <systemitem role="package">devscripts</systemitem> package
1931  might be helpful.  might be helpful.
1932  </para>  </para>
1933  <para>  <para>
# Line 1937  practices that the maintainer might be u Line 1936  practices that the maintainer might be u
1936  the burden of getting your changes integrated back in the normal package  the burden of getting your changes integrated back in the normal package
1937  workflow and thus increases the possibilities that that will happen. A good  workflow and thus increases the possibilities that that will happen. A good
1938  place where to look for for possible package-specific practices is  place where to look for for possible package-specific practices is
1939  <ulink url="&url-debian-policy;ch-source.html#s-readmesource"><literal>debian/README.source</literal></ulink>.  <ulink url="&url-debian-policy;ch-source.html#s-readmesource"><filename>debian/README.source</filename></ulink>.
1940  </para>  </para>
1941  <para>  <para>
1942  Unless you have an excellent reason not to do so, you must then give some time  Unless you have an excellent reason not to do so, you must then give some time
# Line 1995  defend the wisdom of any NMU you perform Line 1994  defend the wisdom of any NMU you perform
1994  </section>  </section>
1995    
1996  <section id="nmu-changelog">  <section id="nmu-changelog">
1997  <title>NMUs and debian/changelog</title>  <title>NMUs and <filename>debian/changelog</filename></title>
1998  <para>  <para>
1999  Just like any other (source) upload, NMUs must add an entry to  Just like any other (source) upload, NMUs must add an entry to
2000  <literal>debian/changelog</literal>, telling what has changed with this  <filename>debian/changelog</filename>, telling what has changed with this
2001  upload.  The first line of this entry must explicitely mention that this upload is an NMU, e.g.:  upload.  The first line of this entry must explicitely mention that this upload is an NMU, e.g.:
2002  </para>  </para>
2003  <screen>  <screen>
# Line 2009  upload.  The first line of this entry mu Line 2008  upload.  The first line of this entry mu
2008  The way to version NMUs differs for native and non-native packages.  The way to version NMUs differs for native and non-native packages.
2009  </para>  </para>
2010  <para>  <para>
2011  If the package is a native package (without a debian revision in the version number),  If the package is a native package (without a Debian revision in the version number),
2012  the version must be the version of the last maintainer upload, plus  the version must be the version of the last maintainer upload, plus
2013  <literal>+nmu<replaceable>X</replaceable></literal>, where  <literal>+nmu<replaceable>X</replaceable></literal>, where
2014  <replaceable>X</replaceable> is a counter starting at <literal>1</literal>.  <replaceable>X</replaceable> is a counter starting at <literal>1</literal>.
# Line 2020  version <literal>1.5+nmu1</literal>. Line 2019  version <literal>1.5+nmu1</literal>.
2019  </para>  </para>
2020  <para>  <para>
2021  If the package is a not a native package, you should add a minor version number  If the package is a not a native package, you should add a minor version number
2022  to the debian revision part of the version number (the portion after the last  to the Debian revision part of the version number (the portion after the last
2023  hyphen). This extra number must start at 1.  For example,  hyphen). This extra number must start at <literal>1</literal>.  For example,
2024  if the current version is <literal>1.5-2</literal>, then an NMU would get  if the current version is <literal>1.5-2</literal>, then an NMU would get
2025  version <literal>1.5-2.1</literal>. If a new upstream version  version <literal>1.5-2.1</literal>. If a new upstream version
2026  is packaged in the NMU, the debian revision is set to <literal>0</literal>, for  is packaged in the NMU, the Debian revision is set to <literal>0</literal>, for
2027  example <literal>1.6-0.1</literal>.  example <literal>1.6-0.1</literal>.
2028  </para>  </para>
2029  <para>  <para>
# Line 2054  should be used, where <replaceable>X</re Line 2053  should be used, where <replaceable>X</re
2053  When the release number is not yet known (often the case for  When the release number is not yet known (often the case for
2054  <literal>testing</literal>, at the beginning of release cycles), the lowest  <literal>testing</literal>, at the beginning of release cycles), the lowest
2055  release number higher than the last stable release number must be used.  For  release number higher than the last stable release number must be used.  For
2056  example, while Etch (Debian 4.0) is stable, a security NMU to stable for a  example, while Lenny (Debian 5.0) is stable, a security NMU to stable for a
2057  package at version <literal>1.5-3</literal> would have version  package at version <literal>1.5-3</literal> would have version
2058  <literal>1.5-3+deb40u1</literal>, whereas a security NMU to Lenny would get  <literal>1.5-3+deb50u1</literal>, whereas a security NMU to Squeeze would get
2059  version <literal>1.5-3+deb50u1</literal>. After the release of Lenny, security  version <literal>1.5-3+deb60u1</literal>. After the release of Squeeze, security
2060  uploads to the <literal>testing</literal> distribution will be versioned  uploads to the <literal>testing</literal> distribution will be versioned
2061  <literal>+deb51uZ</literal>, until it is known whether that release will be  <literal>+deb61uZ</literal>, until it is known whether that release will be
2062  Debian 5.1 or Debian 6.0 (if that becomes the case, uploads will be versioned  Debian 6.1 or Debian 7.0 (if that becomes the case, uploads will be versioned
2063  as <literal>+deb60uZ</literal>.  as <literal>+deb70uZ</literal>).
2064  </para>  </para>
2065  </section>  </section>
2066    
# Line 2138  package is used. Line 2137  package is used.
2137    
2138  <para>  <para>
2139  BinNMUs are usually triggered on the buildds by wanna-build.  BinNMUs are usually triggered on the buildds by wanna-build.
2140  An entry is added to debian/changelog,  An entry is added to <filename>debian/changelog</filename>,
2141  explaining why the upload was needed and increasing the version number as  explaining why the upload was needed and increasing the version number as
2142  described in <xref linkend="binary-only-nmu"/>.  described in <xref linkend="binary-only-nmu"/>.
2143  This entry should not be included in the next upload.  This entry should not be included in the next upload.
# Line 2147  This entry should not be included in the Line 2146  This entry should not be included in the
2146  <para>  <para>
2147  Buildds upload packages for their architecture to the archive as binary-only  Buildds upload packages for their architecture to the archive as binary-only
2148  uploads.  Strictly speaking, these are binNMUs.  However, they are not normally  uploads.  Strictly speaking, these are binNMUs.  However, they are not normally
2149  called NMU, and they don't add an entry to debian/changelog.  called NMU, and they don't add an entry to <filename>debian/changelog</filename>.
2150  </para>  </para>
2151    
2152  </section>  </section>
# Line 2165  uploads are uploads of orphaned packages Line 2164  uploads are uploads of orphaned packages
2164  <para>  <para>
2165  QA uploads are very much like normal maintainer uploads: they may fix anything,  QA uploads are very much like normal maintainer uploads: they may fix anything,
2166  even minor issues; the version numbering is normal, and there is no need to use  even minor issues; the version numbering is normal, and there is no need to use
2167  a delayed upload.  The difference is that you are not listed as the Maintainer  a delayed upload.  The difference is that you are not listed as the <literal>Maintainer</literal>
2168  or Uploader for the package.  Also, the changelog entry of a QA upload has a  or <literal>Uploader</literal> for the package.  Also, the changelog entry of a QA upload has a
2169  special first line:  special first line:
2170  </para>  </para>
2171    
# Line 2199  the new version (see <xref linkend="adop Line 2198  the new version (see <xref linkend="adop
2198    
2199  <para>  <para>
2200  Sometimes you are fixing and/or updating a package because you are member of a  Sometimes you are fixing and/or updating a package because you are member of a
2201  packaging team (which uses a mailing list as Maintainer or Uploader, see <xref  packaging team (which uses a mailing list as <literal>Maintainer</literal> or <literal>Uploader</literal>, see <xref
2202  linkend="collaborative-maint"/>) but you don't want to add yourself to Uploaders  linkend="collaborative-maint"/>) but you don't want to add yourself to <literal>Uploaders</literal>
2203  because you do not plan to contribute regularly to this specific package. If it  because you do not plan to contribute regularly to this specific package. If it
2204  conforms with your team's policy, you can perform a normal upload without  conforms with your team's policy, you can perform a normal upload without
2205  being listed directly as Maintainer or Uploader. In that case, you should  being listed directly as <literal>Maintainer</literal> or <literal>Uploader</literal>. In that case, you should
2206  start your changelog entry with the following line: <code> * Team upload.</code>.  start your changelog entry with the following line:
2207  </para>  </para>
2208    
2209    <screen>
2210     * Team upload.
2211    </screen>
2212    
2213  </section>  </section>
2214    
2215  </section>  </section>
# Line 2218  Collaborative maintenance is a term desc Line 2221  Collaborative maintenance is a term desc
2221  maintenance duties by several people.  This collaboration is almost always a  maintenance duties by several people.  This collaboration is almost always a
2222  good idea, since it generally results in higher quality and faster bug fix  good idea, since it generally results in higher quality and faster bug fix
2223  turnaround times.  It is strongly recommended that packages with a priority of  turnaround times.  It is strongly recommended that packages with a priority of
2224  <literal>Standard</literal> or which are part of the base set have  <literal>standard</literal> or which are part of the base set have
2225  co-maintainers.  co-maintainers.
2226  </para>  </para>
2227  <para>  <para>
# Line 2238  easy: Line 2241  easy:
2241  <para>  <para>
2242  Setup the co-maintainer with access to the sources you build the package from.  Setup the co-maintainer with access to the sources you build the package from.
2243  Generally this implies you are using a network-capable version control system,  Generally this implies you are using a network-capable version control system,
2244  such as <command>CVS</command> or <command>Subversion</command>.  Alioth (see  such as <literal>CVS</literal> or <literal>Subversion</literal>.  Alioth (see
2245  <xref linkend="alioth"/>) provides such tools, amongst others.  <xref linkend="alioth"/>) provides such tools, amongst others.
2246  </para>  </para>
2247  </listitem>  </listitem>
# Line 2262  should subscribe themselves to the appro Line 2265  should subscribe themselves to the appro
2265  <para>  <para>
2266  Another form of collaborative maintenance is team maintenance, which is  Another form of collaborative maintenance is team maintenance, which is
2267  recommended if you maintain several packages with the same group of developers.  recommended if you maintain several packages with the same group of developers.
2268  In that case, the Maintainer and Uploaders field of each package must be  In that case, the <literal>Maintainer</literal> and <literal>Uploaders</literal> field of each package must be
2269  managed with care.  It is recommended to choose between one of the two  managed with care.  It is recommended to choose between one of the two
2270  following schemes:  following schemes:
2271  </para>  </para>
2272  <orderedlist numeration="arabic">  <orderedlist numeration="arabic">
2273  <listitem>  <listitem>
2274  <para>  <para>
2275  Put the team member mainly responsible for the package in the Maintainer field.  Put the team member mainly responsible for the package in the <literal>Maintainer</literal> field.
2276  In the Uploaders, put the mailing list address, and the team members who care  In the <literal>Uploaders</literal>, put the mailing list address, and the team members who care
2277  for the package.  for the package.
2278  </para>  </para>
2279  </listitem>  </listitem>
2280  <listitem>  <listitem>
2281  <para>  <para>
2282  Put the mailing list address in the Maintainer field.  In the Uploaders field,  Put the mailing list address in the <literal>Maintainer</literal> field.  In the <literal>Uploaders</literal> field,
2283  put the team members who care for the package.  In this case, you must make  put the team members who care for the package.  In this case, you must make
2284  sure the mailing list accept bug reports without any human interaction (like  sure the mailing list accept bug reports without any human interaction (like
2285  moderation for non-subscribers).  moderation for non-subscribers).
# Line 2286  moderation for non-subscribers). Line 2289  moderation for non-subscribers).
2289    
2290  <para>  <para>
2291  In any case, it is a bad idea to automatically put all team members in the  In any case, it is a bad idea to automatically put all team members in the
2292  Uploaders field. It clutters the Developer's Package Overview listing (see  <literal>Uploaders</literal> field. It clutters the Developer's Package Overview listing (see
2293  <xref linkend="ddpo"/>) with packages one doesn't really care for, and creates  <xref linkend="ddpo"/>) with packages one doesn't really care for, and creates
2294  a false sense of good maintenance. For the same reason, team members do  a false sense of good maintenance. For the same reason, team members do
2295  not need to add themselves to the Uploaders field just because they are  not need to add themselves to the <literal>Uploaders</literal> field just because they are
2296  uploading the package once, they can do a “Team upload” (see <xref  uploading the package once, they can do a “Team upload” (see <xref
2297  linkend="nmu-team-upload"/>). Conversely, it it a bad idea to keep a  linkend="nmu-team-upload"/>). Conversely, it is a bad idea to keep a
2298  package with only the mailing list address as a Maintainer and no  package with only the mailing list address as a <literal>Maintainer</literal> and no
2299  Uploaders.  <literal>Uploaders</literal>.
2300  </para>  </para>
2301  </section>  </section>
2302    
# Line 2309  after they have undergone some degree of Line 2312  after they have undergone some degree of
2312  <para>  <para>
2313  They must be in sync on all architectures and mustn't have dependencies that  They must be in sync on all architectures and mustn't have dependencies that
2314  make them uninstallable; they also have to have generally no known  make them uninstallable; they also have to have generally no known
2315  release-critical bugs at the time they're installed into <literal>testing  release-critical bugs at the time they're installed into <literal>testing</literal>.
2316  </literal>.  This way, <literal>testing</literal> should always be close to  This way, <literal>testing</literal> should always be close to
2317  being a release candidate.  Please see below for details.  being a release candidate.  Please see below for details.
2318  </para>  </para>
2319  </section>  </section>
# Line 2350  available in <literal>unstable</literal> Line 2353  available in <literal>unstable</literal>
2353  <listitem>  <listitem>
2354  <para>  <para>
2355  It must be available on all architectures on which it has previously been built  It must be available on all architectures on which it has previously been built
2356  in <literal>unstable</literal>.  <xref linkend="dak-ls"/> may be of interest  in <literal>unstable</literal>. <link linkend="dak-ls">dak ls</link> may be of interest
2357  to check that information;  to check that information;
2358  </para>  </para>
2359  </listitem>  </listitem>
# Line 2365  It must not break any dependency of a pa Line 2368  It must not break any dependency of a pa
2368  The packages on which it depends must either be available in  The packages on which it depends must either be available in
2369  <literal>testing</literal> or they must be accepted into  <literal>testing</literal> or they must be accepted into
2370  <literal>testing</literal> at the same time (and they will be if they fulfill  <literal>testing</literal> at the same time (and they will be if they fulfill
2371  all the necessary criteria);  all the necessary criteria).
2372  </para>  </para>
2373  </listitem>  </listitem>
2374  </itemizedlist>  </itemizedlist>
# Line 2398  url="http://release.debian.org/migration Line 2401  url="http://release.debian.org/migration
2401  shows build dependencies which are not considered by britney.  shows build dependencies which are not considered by britney.
2402  </para>  </para>
2403  <section id="outdated">  <section id="outdated">
2404  <title>out-of-date</title>  <title>Out-of-date</title>
2405  <para>  <para>
2406  <!-- FIXME: better rename this file than document rampant professionalism? -->  <!-- FIXME: better rename this file than document rampant professionalism? -->
2407  For the <literal>testing</literal> migration script, outdated means: There are  For the <literal>testing</literal> migration script, outdated means: There are
# Line 2435  Consider this example: Line 2438  Consider this example:
2438  </tgroup>  </tgroup>
2439  </informaltable>  </informaltable>
2440  <para>  <para>
2441  The package is out of date on alpha in <literal>unstable</literal>, and will  The package is out of date on <literal>alpha</literal> in <literal>unstable</literal>, and will
2442  not go to <literal>testing</literal>. Removing the package would not help at all, the  not go to <literal>testing</literal>. Removing the package would not help at all, the
2443  package is still out of date on <literal>alpha</literal>, and will not  package is still out of date on <literal>alpha</literal>, and will not
2444  propagate to testing.  propagate to <literal>testing</literal>.
2445  </para>  </para>
2446  <para>  <para>
2447  However, if ftp-master removes a package in <literal>unstable</literal> (here  However, if ftp-master removes a package in <literal>unstable</literal> (here
# Line 2492  with the new version of <literal>b</lite Line 2495  with the new version of <literal>b</lite
2495  be removed to allow <literal>b</literal> in.  be removed to allow <literal>b</literal> in.
2496  </para>  </para>
2497  <para>  <para>
2498  Of course, there is another reason to remove a package from <literal>testing  Of course, there is another reason to remove a package from <literal>testing</literal>:
2499  </literal>: It's just too buggy (and having a single RC-bug is enough to be  It's just too buggy (and having a single RC-bug is enough to be
2500  in this state).  in this state).
2501  </para>  </para>
2502  <para>  <para>
# Line 2504  will automatically be removed. Line 2507  will automatically be removed.
2507  </section>  </section>
2508    
2509  <section id="circular">  <section id="circular">
2510  <title>circular dependencies</title>  <title>Circular dependencies</title>
2511  <para>  <para>
2512  A situation which is not handled very well by britney is if package  A situation which is not handled very well by britney is if package
2513  <literal>a</literal> depends on the new version of package  <literal>a</literal> depends on the new version of package
# Line 2548  happens to one of your packages. Line 2551  happens to one of your packages.
2551  </section>  </section>
2552    
2553  <section id="s5.13.2.4">  <section id="s5.13.2.4">
2554  <title>influence of package in testing</title>  <title>Influence of package in testing</title>
2555  <para>  <para>
2556  Generally, there is nothing that the status of a package in <literal>testing  Generally, there is nothing that the status of a package in <literal>testing</literal>
2557  </literal> means for transition of the next version from <literal>unstable  means for transition of the next version from <literal>unstable</literal>
2558  </literal> to <literal>testing</literal>, with two exceptions:  to <literal>testing</literal>, with two exceptions:
2559  If the RC-bugginess of the package goes down, it may go in even if it is still  If the RC-bugginess of the package goes down, it may go in even if it is still
2560  RC-buggy.  The second exception is if the version of the package in <literal>  RC-buggy.  The second exception is if the version of the package in
2561  testing</literal> is out of sync on the different arches: Then any arch might  <literal>testing</literal> is out of sync on the different arches: Then any arch might
2562  just upgrade to the version of the source package; however, this can happen  just upgrade to the version of the source package; however, this can happen
2563  only if the package was previously forced through, the arch is in fuckedarches,  only if the package was previously forced through, the arch is in fuckedarches,
2564  or there was no binary package of that arch present in <literal>unstable  or there was no binary package of that arch present in <literal>unstable</literal>
2565  </literal> at all during the <literal>testing</literal> migration.  at all during the <literal>testing</literal> migration.
2566  </para>  </para>
2567  <para>  <para>
2568  In summary this means: The only influence that a package being in <literal>  In summary this means: The only influence that a package being in
2569  testing</literal> has on a new version of the same package is that the new  <literal>testing</literal> has on a new version of the same package is that the new
2570  version might go in easier.  version might go in easier.
2571  </para>  </para>
2572  </section>  </section>
2573    
2574  <section id="details">  <section id="details">
2575  <title>details</title>  <title>Details</title>
2576  <para>  <para>
2577  If you are interested in details, this is how britney works:  If you are interested in details, this is how britney works:
2578  </para>  </para>
# Line 2583  part of britney.) (There is a similar th Line 2586  part of britney.) (There is a similar th
2586  is not described here.  If you're interested in that, please peruse the code.)  is not described here.  If you're interested in that, please peruse the code.)
2587  </para>  </para>
2588  <para>  <para>
2589  Now, the more complex part happens: Britney tries to update <literal>testing  Now, the more complex part happens: Britney tries to update <literal>testing</literal>
2590  </literal> with the valid candidates. For that, britney tries to add each  with the valid candidates. For that, britney tries to add each
2591  valid candidate to the testing distribution. If the number of uninstallable  valid candidate to the testing distribution. If the number of uninstallable
2592  packages in <literal>testing</literal> doesn't increase, the package is  packages in <literal>testing</literal> doesn't increase, the package is
2593  accepted. From that point on, the accepted package is considered to be part  accepted. From that point on, the accepted package is considered to be part
# Line 2597  If you want to see more details, you can Line 2600  If you want to see more details, you can
2600  <filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or  <filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or
2601  in <filename>merkel:~aba/testing/update_out</filename> to see a setup with  in <filename>merkel:~aba/testing/update_out</filename> to see a setup with
2602  a smaller packages file).  Via web, it's at <ulink  a smaller packages file).  Via web, it's at <ulink
2603  url="http://&ftp-master-host;/testing/update_out_code/"></ulink>  url="http://&ftp-master-host;/testing/update_out_code/"></ulink>.
2604  </para>  </para>
2605  <para>  <para>
2606  The hints are available via <ulink  The hints are available via <ulink
# Line 2612  url="http://&ftp-master-host;/testing/hi Line 2615  url="http://&ftp-master-host;/testing/hi
2615  <para>  <para>
2616  The <literal>testing</literal> distribution is fed with packages from  The <literal>testing</literal> distribution is fed with packages from
2617  <literal>unstable</literal> according to the rules explained above.  However,  <literal>unstable</literal> according to the rules explained above.  However,
2618  in some cases, it is necessary to upload packages built only for <literal>  in some cases, it is necessary to upload packages built only for
2619  testing</literal>.  For that, you may want to upload to <literal>  <literal>testing</literal>.  For that, you may want to upload to
2620  testing-proposed-updates</literal>.  <literal>testing-proposed-updates</literal>.
2621  </para>  </para>
2622  <para>  <para>
2623  Keep in mind that packages uploaded there are not automatically processed, they  Keep in mind that packages uploaded there are not automatically processed, they
# Line 2626  give on &email-debian-devel-announce;. Line 2629  give on &email-debian-devel-announce;.
2629  <para>  <para>
2630  You should not upload to <literal>testing-proposed-updates</literal> when you  You should not upload to <literal>testing-proposed-updates</literal> when you
2631  can update your packages through <literal>unstable</literal>.  If you can't  can update your packages through <literal>unstable</literal>.  If you can't
2632  (for example because you have a newer development version in <literal>unstable  (for example because you have a newer development version in <literal>unstable</literal>),
2633  </literal>), you may use this facility, but it is recommended that you ask for  you may use this facility, but it is recommended that you ask for
2634  authorization from the release manager first.  Even if a package is frozen,  authorization from the release manager first.  Even if a package is frozen,
2635  updates through <literal>unstable</literal> are possible, if the upload via  updates through <literal>unstable</literal> are possible, if the upload via
2636  <literal>unstable</literal> does not pull in any new dependencies.  <literal>unstable</literal> does not pull in any new dependencies.
# Line 2635  updates through <literal>unstable</liter Line 2638  updates through <literal>unstable</liter
2638  <para>  <para>
2639  Version numbers are usually selected by adding the codename of the  Version numbers are usually selected by adding the codename of the
2640  <literal>testing</literal> distribution and a running number, like  <literal>testing</literal> distribution and a running number, like
2641  <literal>1.2sarge1</literal> for the first upload through  <literal>1.2squeeze1</literal> for the first upload through
2642  <literal>testing-proposed-updates</literal> of package version  <literal>testing-proposed-updates</literal> of package version
2643  <literal>1.2</literal>.  <literal>1.2</literal>.
2644  </para>  </para>
# Line 2646  Please make sure you didn't miss any of Line 2649  Please make sure you didn't miss any of
2649  <listitem>  <listitem>
2650  <para>  <para>
2651  Make sure that your package really needs to go through  Make sure that your package really needs to go through
2652  <literal>testing-proposed-updates</literal>, and can't go through <literal>  <literal>testing-proposed-updates</literal>, and can't go through
2653  unstable</literal>;  <literal>unstable</literal>;
2654  </para>  </para>
2655  </listitem>  </listitem>
2656  <listitem>  <listitem>
# Line 2701  currently, these are <literal>critical</ Line 2704  currently, these are <literal>critical</
2704  Such bugs are presumed to have an impact on the chances that the package will  Such bugs are presumed to have an impact on the chances that the package will
2705  be released with the <literal>stable</literal> release of Debian: in general,  be released with the <literal>stable</literal> release of Debian: in general,
2706  if a package has open release-critical bugs filed on it, it won't get into  if a package has open release-critical bugs filed on it, it won't get into
2707  <literal>testing</literal>, and consequently won't be released in <literal>  <literal>testing</literal>, and consequently won't be released in
2708  stable</literal>.  <literal>stable</literal>.
2709  </para>  </para>
2710  <para>  <para>
2711  The <literal>unstable</literal> bug count are all release-critical bugs which  The <literal>unstable</literal> bug count are all release-critical bugs which
2712  are marked to apply to <replaceable>package</replaceable>/<replaceable>version  are marked to apply to <replaceable>package</replaceable>/<replaceable>version</replaceable>
2713  </replaceable> combinations that are available in unstable for a release  combinations that are available in unstable for a release
2714  architecture. The <literal>testing</literal> bug count is defined analogously.  architecture. The <literal>testing</literal> bug count is defined analogously.
2715  </para>  </para>
2716  </section>  </section>
# Line 2719  break other packages?</title> Line 2722  break other packages?</title>
2722  The structure of the distribution archives is such that they can only contain  The structure of the distribution archives is such that they can only contain
2723  one version of a package; a package is defined by its name.  So when the source  one version of a package; a package is defined by its name.  So when the source
2724  package <literal>acmefoo</literal> is installed into <literal>testing</literal>,  package <literal>acmefoo</literal> is installed into <literal>testing</literal>,
2725  along with its binary packages <literal>acme-foo-bin</literal>, <literal>  along with its binary packages <literal>acme-foo-bin</literal>,
2726  acme-bar-bin</literal>, <literal>libacme-foo1</literal> and <literal>  <literal>acme-bar-bin</literal>, <literal>libacme-foo1</literal> and
2727  libacme-foo-dev</literal>, the old version is removed.  <literal>libacme-foo-dev</literal>, the old version is removed.
2728  </para>  </para>
2729  <para>  <para>
2730  However, the old version may have provided a binary package with an old soname  However, the old version may have provided a binary package with an old soname
Legend:
Removed from v.7314  
changed lines
  Added in v.8539
  ViewVC Help
Powered by ViewVC 1.1.5