/[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 5196 by he, Sun Jun 1 14:28:18 2008 UTC revision 5199 by he, Sun Jun 1 15:47:07 2008 UTC
# Line 72  already is a volunteer, so efforts may b Line 72  already is a volunteer, so efforts may b
72  <para>  <para>
73  It lets the rest of the maintainers know more about the package than the one  It lets the rest of the maintainers know more about the package than the one
74  line description and the usual changelog entry ``Initial release'' that gets  line description and the usual changelog entry ``Initial release'' that gets
75  posted to <literal>debian-devel-changes</literal>.  posted to &email-debian-devel-changes;.
76  </para>  </para>
77  </listitem>  </listitem>
78  <listitem>  <listitem>
79  <para>  <para>
80  It is helpful to the people who live off unstable (and form our first line of  It is helpful to the people who live off <literal>unstable</literal> (and form
81  testers).  We should encourage these people.  our first line of testers).  We should encourage these people.
82  </para>  </para>
83  </listitem>  </listitem>
84  <listitem>  <listitem>
# Line 269  The package build process extracts this Line 269  The package build process extracts this
269  <literal>Distribution</literal> field of the <literal>.changes</literal> file.  <literal>Distribution</literal> field of the <literal>.changes</literal> file.
270  </para>  </para>
271  <para>  <para>
272  There are several possible values for this field: `stable', `unstable',  There are several possible values for this field: <literal>stable</literal>,
273  `testing-proposed-updates' and `experimental'.  Normally, packages are uploaded  <literal>unstable</literal>, <litersl>testing-proposed-updates</literal> and
274  into <literal>unstable</literal>.  <literal>experimental</literal>.  Normally, packages are uploaded into
275    <literal>unstable</literal>.
276  </para>  </para>
277  <para>  <para>
278  Actually, there are two other possible distributions: `stable-security' and  Actually, there are two other possible distributions: <literal>stable-security
279  `testing-security', but read <xref linkend="bug-security"/> for more  </literal> and <literal>testing-security</literal>, but read
280  information on those.  <xref linkend="bug-security"/> for more information on those.
281  </para>  </para>
282  <para>  <para>
283  It is not possible to upload a package into several distributions at the same  It is not possible to upload a package into several distributions at the same
# Line 294  point release. Line 295  point release.
295  </para>  </para>
296  <para>  <para>
297  Extra care should be taken when uploading to <literal>stable</literal>.  Extra care should be taken when uploading to <literal>stable</literal>.
298  Basically, a package should only be uploaded to stable if one of the following  Basically, a package should only be uploaded to <literal>stable</literal> if
299  happens:  one of the following happens:
300  </para>  </para>
301  <itemizedlist>  <itemizedlist>
302  <listitem>  <listitem>
# Line 331  Packages uploaded to <literal>stable</li Line 332  Packages uploaded to <literal>stable</li
332  running <literal>stable</literal>, so that their dependencies are limited to  running <literal>stable</literal>, so that their dependencies are limited to
333  the libraries (and other packages) available in <literal>stable</literal>;  the libraries (and other packages) available in <literal>stable</literal>;
334  for example, a package uploaded to <literal>stable</literal> that depends on  for example, a package uploaded to <literal>stable</literal> that depends on
335  a library package that only exists in unstable will be rejected.  Making  a library package that only exists in <literal>unstable</literal> will be
336  changes to dependencies of other packages (by messing with  rejected.  Making changes to dependencies of other packages (by messing with
337  <literal>Provides</literal> or shlibs files), possibly making those other  <literal>Provides</literal> or <literal>shlibs</literal> files), possibly
338  packages uninstallable, is strongly discouraged.  making those other packages uninstallable, is strongly discouraged.
339  </para>  </para>
340  <para>  <para>
341  The Release Team (which can be reached at  The Release Team (which can be reached at
# Line 424  linkend="upload-ftp-master"/> applies he Line 425  linkend="upload-ftp-master"/> applies he
425  <title>Security uploads</title>  <title>Security uploads</title>
426  <para>  <para>
427  Do <emphasis role="strong">NOT</emphasis> upload a package to the security  Do <emphasis role="strong">NOT</emphasis> upload a package to the security
428  upload queue (oldstable-security, stable-security, etc.) without prior  upload queue (<literal>oldstable-security</literal>, <literal>stable-security
429  authorization from the security team.  If the package does not exactly meet the  </literal>, etc.) without prior authorization from the security team.  If the
430  team's requirements, it will cause many problems and delays in dealing with the  package does not exactly meet the team's requirements, it will cause many
431  unwanted upload.  For details, please see section <xref  problems and delays in dealing with the unwanted upload.  For details, please
432  linkend="bug-security"/> .  see section <xref linkend="bug-security"/> .
433  </para>  </para>
434  </section>  </section>
435    
436  <section id="s5.6.5">  <section id="s5.6.5">
437  <title>Other upload queues</title>  <title>Other upload queues</title>
438  <para>  <para>
439  The scp queues on <literal>&ftp-master-host;</literal>, and security are mostly  The scp queues on <literal>&ftp-master-host;</literal>, and <literal>
440  unusable due to the login restrictions on those hosts.  security.debian.org</literal> are mostly unusable due to the login restrictions
441    on those hosts.
442  </para>  </para>
443  <para>  <para>
444  The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently  The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently
# Line 448  ftp.chiark.greenend.org.uk are down perm Line 450  ftp.chiark.greenend.org.uk are down perm
450  The queue in Japan will be replaced with a new queue on hp.debian.or.jp some  The queue in Japan will be replaced with a new queue on hp.debian.or.jp some
451  day.  day.
452  </para>  </para>
 <para>  
 For the time being, the anonymous ftp queue on auric.debian.org (the former  
 ftp-master) works, but it is deprecated and will be removed at some point in  
 the future.  
 </para>  
453  </section>  </section>
454    
455  <section id="upload-notification">  <section id="upload-notification">
# Line 461  the future. Line 458  the future.
458  The Debian archive maintainers are responsible for handling package uploads.  The Debian archive maintainers are responsible for handling package uploads.
459  For the most part, uploads are automatically handled on a daily basis by the  For the most part, uploads are automatically handled on a daily basis by the
460  archive maintenance tools, <command>katie</command>.  Specifically, updates to  archive maintenance tools, <command>katie</command>.  Specifically, updates to
461  existing packages to the `unstable' distribution are handled automatically.  In  existing packages to the <literal>unstable</literal> distribution are handled
462  other cases, notably new packages, placing the uploaded package into the  automatically.  In other cases, notably new packages, placing the uploaded
463  distribution is handled manually.  When uploads are handled manually, the  package into the distribution is handled manually.  When uploads are handled
464  change to the archive may take up to a month to occur.  Please be patient.  manually, the change to the archive may take up to a month to occur.  Please
465    be patient.
466  </para>  </para>
467  <para>  <para>
468  In any case, you will receive an email notification indicating that the package  In any case, you will receive an email notification indicating that the package
# Line 808  Due to their sensitive nature, security- Line 806  Due to their sensitive nature, security-
806  The Debian Security Team exists to coordinate this activity, keeping track of  The Debian Security Team exists to coordinate this activity, keeping track of
807  outstanding security problems, helping maintainers with security problems or  outstanding security problems, helping maintainers with security problems or
808  fixing them themselves, sending security advisories, and maintaining  fixing them themselves, sending security advisories, and maintaining
809  security.debian.org.  <literal>security.debian.org</literal>.
810  </para>  </para>
811  <!-- information about the security database goes here once it's ready -->  <!-- information about the security database goes here once it's ready -->
812  <!-- (mdz) -->  <!-- (mdz) -->
# Line 817  When you become aware of a security-rela Line 815  When you become aware of a security-rela
815  not you are the maintainer, collect pertinent information about the problem,  not you are the maintainer, collect pertinent information about the problem,
816  and promptly contact the security team at  and promptly contact the security team at
817  &email-security-team; as soon as possible.  <emphasis  &email-security-team; as soon as possible.  <emphasis
818  role="strong">DO NOT UPLOAD</emphasis> any packages for stable; the security  role="strong">DO NOT UPLOAD</emphasis> any packages for <literal>stable</literal>;
819  team will do that.  Useful information includes, for example:   the security team will do that.  Useful information includes, for example:
820  </para>  </para>
821  <itemizedlist>  <itemizedlist>
822  <listitem>  <listitem>
823  <para>  <para>
824  Which versions of the package are known to be affected by the bug.  Check each  Which versions of the package are known to be affected by the bug.  Check each
825  version that is present in a supported Debian release, as well as testing and  version that is present in a supported Debian release, as well as
826  unstable.  <literal>testing</literal> and <literal>unstable</literal>.
827  </para>  </para>
828  </listitem>  </listitem>
829  <listitem>  <listitem>
# Line 911  release of Debian.  When sending confide Line 909  release of Debian.  When sending confide
909  be sure to mention this fact.  be sure to mention this fact.
910  </para>  </para>
911  <para>  <para>
912  Please note that if secrecy is needed you may not upload a fix to unstable (or  Please note that if secrecy is needed you may not upload a fix to
913    <literal>unstable</literal> (or
914  anywhere else, such as a public CVS repository).  It is not sufficient to  anywhere else, such as a public CVS repository).  It is not sufficient to
915  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
916  will) be examined by the general public.  will) be examined by the general public.
# Line 927  has become public. Line 926  has become public.
926  <title>Security Advisories</title>  <title>Security Advisories</title>
927  <para>  <para>
928  Security advisories are only issued for the current, released stable  Security advisories are only issued for the current, released stable
929  distribution, and <emphasis>not</emphasis> for testing or unstable.  When  distribution, and <emphasis>not</emphasis> for <literal>testing</literal>
930  released, advisories are sent to the  or <literal>unstable</literal>.  When released, advisories are sent to the
931  &email-debian-security-announce; mailing list and posted on  &email-debian-security-announce; mailing list and posted on
932  <ulink url="&url-debian-security-advisories;">the security web  <ulink url="&url-debian-security-advisories;">the security web
933  page</ulink>.  Security advisories are written and posted by the security team.  page</ulink>.  Security advisories are written and posted by the security team.
# Line 1058  Be sure to verify the following items: Line 1057  Be sure to verify the following items:
1057  <listitem>  <listitem>
1058  <para>  <para>
1059  Target the right distribution in your <filename>debian/changelog</filename>.  Target the right distribution in your <filename>debian/changelog</filename>.
1060  For stable this is <literal>stable-security</literal> and for testing this is  For <literal>stable</literal> this is <literal>stable-security</literal> and
1061  <literal>testing-security</literal>, and for the previous stable release, this  for testing this is <literal>testing-security</literal>, and for the previous
1062  is <literal>oldstable-security</literal>.  Do not target  stable release, this is <literal>oldstable-security</literal>.  Do not target
1063  <replaceable>distribution</replaceable><literal>-proposed-updates</literal> or  <replaceable>distribution</replaceable><literal>-proposed-updates</literal> or
1064  <literal>stable</literal>!  <literal>stable</literal>!
1065  </para>  </para>
# Line 1075  The upload should have urgency=high. Line 1074  The upload should have urgency=high.
1074  Make descriptive, meaningful changelog entries.  Others will rely on them to  Make descriptive, meaningful changelog entries.  Others will rely on them to
1075  determine whether a particular bug was fixed.  Always include an external  determine whether a particular bug was fixed.  Always include an external
1076  reference, preferably a CVE identifier, so that it can be cross-referenced.  reference, preferably a CVE identifier, so that it can be cross-referenced.
1077  Include the same information in the changelog for unstable, so that it is clear  Include the same information in the changelog for <literal>unstable</literal>,
1078    so that it is clear
1079  that the same bug was fixed, as this is very helpful when verifying that the  that the same bug was fixed, as this is very helpful when verifying that the
1080  bug is fixed in the next stable release.  If a CVE identifier has not yet been  bug is fixed in the next stable release.  If a CVE identifier has not yet been
1081  assigned, the security team will request one so that it can be included in the  assigned, the security team will request one so that it can be included in the
# Line 1091  re-use a version number that you have al Line 1091  re-use a version number that you have al
1091  <literal>testing</literal>, there must be a higher version in  <literal>testing</literal>, there must be a higher version in
1092  <literal>unstable</literal>.  If there is none yet (for example, if  <literal>unstable</literal>.  If there is none yet (for example, if
1093  <literal>testing</literal> and <literal>unstable</literal> have the same  <literal>testing</literal> and <literal>unstable</literal> have the same
1094  version) you must upload a new version to unstable first.  version) you must upload a new version to <literal>unstable</literal> first.
1095  </para>  </para>
1096  </listitem>  </listitem>
1097  <listitem>  <listitem>
# Line 1105  uploads as well. Line 1105  uploads as well.
1105  </listitem>  </listitem>
1106  <listitem>  <listitem>
1107  <para>  <para>
1108  Unless the upstream source has been uploaded to security.debian.org before (by  Unless the upstream source has been uploaded to <literal>security.debian.org
1109  a previous security update), build the upload with full upstream source  </literal> before (by a previous security update), build the upload with full
1110  (<literal>dpkg-buildpackage -sa</literal>).  If there has been a previous  upstream source (<literal>dpkg-buildpackage -sa</literal>).  If there has been
1111  upload to security.debian.org with the same upstream version, you may upload  a previous upload to </literal>security.debian.org</literal> with the same
1112  without upstream source (<literal>dpkg-buildpackage -sd</literal>).  upstream version, you may upload without upstream source (<literal>
1113    dpkg-buildpackage -sd</literal>).
1114  </para>  </para>
1115  </listitem>  </listitem>
1116  <listitem>  <listitem>
# Line 1135  linkend="debootstrap"/> ). Line 1136  linkend="debootstrap"/> ).
1136  <title>Uploading the fixed package</title>  <title>Uploading the fixed package</title>
1137  <para>  <para>
1138  Do <emphasis role="strong">NOT</emphasis> upload a package to the security  Do <emphasis role="strong">NOT</emphasis> upload a package to the security
1139  upload queue (oldstable-security, stable-security, etc.) without prior  upload queue (<literal>oldstable-security</literal>, <literal>stable-security
1140  authorization from the security team.  If the package does not exactly meet the  </literal>, etc.) without prior authorization from the security team.  If the
1141  team's requirements, it will cause many problems and delays in dealing with the  package does not exactly meet the team's requirements, it will cause many
1142  unwanted upload.  problems and delays in dealing with the unwanted upload.
1143  </para>  </para>
1144  <para>  <para>
1145  Do <emphasis role="strong">NOT</emphasis> upload your fix to proposed-updates  Do <emphasis role="strong">NOT</emphasis> upload your fix to <literal>
1146  without coordinating with the security team.  Packages from security.debian.org  proposed-updates</literal> without coordinating with the security team.
1147  will be copied into the proposed-updates directory automatically.  If a package  Packages from <literal>security.debian.org</literal> will be copied into
1148    the <literal>proposed-updates</literal> directory automatically.  If a package
1149  with the same or a higher version number is already installed into the archive,  with the same or a higher version number is already installed into the archive,
1150  the security update will be rejected by the archive system.  That way, the  the security update will be rejected by the archive system.  That way, the
1151  stable distribution will end up without a security update for this package  stable distribution will end up without a security update for this package
# Line 1167  problems that cannot be disclosed yet. Line 1169  problems that cannot be disclosed yet.
1169  </para>  </para>
1170  <para>  <para>
1171  If a member of the security team accepts a package, it will be installed on  If a member of the security team accepts a package, it will be installed on
1172  security.debian.org as well as proposed for the proper  <literal>security.debian.org</literal> as well as proposed for the proper
1173  <replaceable>distribution</replaceable><literal>-proposed-updates</literal>  <replaceable>distribution</replaceable><literal>-proposed-updates</literal>
1174  on <literal>&ftp-master-host;</literal>.  on <literal>&ftp-master-host;</literal>.
1175  </para>  </para>
# Line 1430  Make sure that your <literal>Build-Depen Line 1432  Make sure that your <literal>Build-Depen
1432  <literal>Build-Depends-Indep</literal> settings in  <literal>Build-Depends-Indep</literal> settings in
1433  <filename>debian/control</filename> are set properly.  The best way to validate  <filename>debian/control</filename> are set properly.  The best way to validate
1434  this is to use the <systemitem role="package">debootstrap</systemitem> package  this is to use the <systemitem role="package">debootstrap</systemitem> package
1435  to create an unstable chroot environment (see <xref linkend="debootstrap"/> ).  to create an <literal>unstable</literal> chroot environment (see <xref
1436    linkend="debootstrap"/> ).
1437  Within that chrooted environment, install the <systemitem  Within that chrooted environment, install the <systemitem
1438  role="package">build-essential</systemitem> package and any package  role="package">build-essential</systemitem> package and any package
1439  dependencies mentioned in <literal>Build-Depends</literal> and/or  dependencies mentioned in <literal>Build-Depends</literal> and/or
# Line 1598  the architecture is a candidate for incl Line 1601  the architecture is a candidate for incl
1601  release managers decide and announce which architectures are candidates.  release managers decide and announce which architectures are candidates.
1602  </para>  </para>
1603  <para>  <para>
1604  If you are a porter doing an NMU for `unstable', the above guidelines for  If you are a porter doing an NMU for <literal>unstable</literal>, the above
1605  porting should be followed, with two variations.  Firstly, the acceptable  guidelines for porting should be followed, with two variations.  Firstly, the
1606  waiting period — the time between when the bug is submitted to the BTS and  acceptable waiting period — the time between when the bug is submitted to
1607  when it is OK to do an NMU — is seven days for porters working on the  the BTS and when it is OK to do an NMU — is seven days for porters working
1608  unstable distribution.  This period can be shortened if the problem is critical  on the <literal>unstable</literal> distribution.  This period can be shortened
1609  and imposes hardship on the porting effort, at the discretion of the porter  if the problem is critical and imposes hardship on the porting effort, at the
1610  group.  (Remember, none of this is Policy, just mutually agreed upon  discretion of the porter group.  (Remember, none of this is Policy, just
1611  guidelines.) For uploads to stable or testing, please coordinate with the  mutually agreed upon guidelines.) For uploads to <literal>stable</literal> or
1612  appropriate release team first.  <literal>testing </literal>, please coordinate with the appropriate release
1613    team first.
1614  </para>  </para>
1615  <para>  <para>
1616  Secondly, porters doing source NMUs should make sure that the bug they submit  Secondly, porters doing source NMUs should make sure that the bug they submit
# Line 1701  also enable Debian to recompile entire d Line 1705  also enable Debian to recompile entire d
1705  </para>  </para>
1706  <para>  <para>
1707  The buildds admins of each arch can be contacted at the mail address  The buildds admins of each arch can be contacted at the mail address
1708  $arch@buildd.debian.org.  <literal><replaceable>arch</replaceable>@buildd.debian.org</literal>.
1709  </para>  </para>
1710  </section>  </section>
1711    
# Line 1810  work. Line 1814  work.
1814  </para>  </para>
1815  <para>  <para>
1816  A NMU should follow all conventions, written down in this section.  For an  A NMU should follow all conventions, written down in this section.  For an
1817  upload to testing or unstable, this order of steps is recommended:  upload to <literal>testing</literal> or <literal>unstable</literal>, this
1818    order of steps is recommended:
1819  </para>  </para>
1820  <itemizedlist>  <itemizedlist>
1821  <listitem>  <listitem>
# Line 1863  contact the developer first, and act lat Line 1868  contact the developer first, and act lat
1868  linkend="qa-bsp"/> for details.  linkend="qa-bsp"/> for details.
1869  </para>  </para>
1870  <para>  <para>
1871  For the testing distribution, the rules may be changed by the release managers.  For the <literal>testing</literal> distribution, the rules may be changed by
1872  Please take additional care, and acknowledge that the usual way for a package  the release managers.  Please take additional care, and acknowledge that the
1873  to enter testing is through unstable.  usual way for a package to enter <literal>testing</literal> is through
1874    <literal>unstable</literal>.
1875  </para>  </para>
1876  <para>  <para>
1877  For the stable distribution, please take extra care.  Of course, the release  For the stable distribution, please take extra care.  Of course, the release
# Line 1923  maintainer of a package should start the Line 1929  maintainer of a package should start the
1929  <replaceable>debian-revision</replaceable> numbering at `1'.  <replaceable>debian-revision</replaceable> numbering at `1'.
1930  </para>  </para>
1931  <para>  <para>
1932  If you upload a package to testing or stable, sometimes, you need to fork the  If you upload a package to <literal>testing</literal> or <literal>stable
1933  version number tree.  For this, version numbers like 1.1-3sarge0.1 could be  </literal>, sometimes, you need to fork the version number tree.  For this,
1934  used.  version numbers like 1.1-3sarge0.1 could be used.
1935  </para>  </para>
1936  </section>  </section>
1937    
# Line 2170  a false sense of good maintenance. Line 2176  a false sense of good maintenance.
2176  <section id="testing-basics">  <section id="testing-basics">
2177  <title>Basics</title>  <title>Basics</title>
2178  <para>  <para>
2179  Packages are usually installed into the `testing' distribution after they have  Packages are usually installed into the <literal>testing</literal> distribution
2180  undergone some degree of testing in unstable.  after they have undergone some degree of <literal>testing</literal> in
2181    <literal>unstable</literal>.
2182  </para>  </para>
2183  <para>  <para>
2184  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
2185  make them uninstallable; they also have to have generally no known  make them uninstallable; they also have to have generally no known
2186  release-critical bugs at the time they're installed into testing.  This way,  release-critical bugs at the time they're installed into <literal>testing
2187  `testing' should always be close to being a release candidate.  Please see  <literal>.  This way, <literal>testing</literal> should always be close to
2188  below for details.  being a release candidate.  Please see below for details.
2189  </para>  </para>
2190  </section>  </section>
2191    
# Line 2202  the following: Line 2209  the following:
2209  The package must have been available in <literal>unstable</literal> for 2, 5  The package must have been available in <literal>unstable</literal> for 2, 5
2210  or 10 days, depending on the urgency (high, medium or low).  Please note that  or 10 days, depending on the urgency (high, medium or low).  Please note that
2211  the urgency is sticky, meaning that the highest urgency uploaded since the  the urgency is sticky, meaning that the highest urgency uploaded since the
2212  previous testing transition is taken into account.  Those delays may be doubled  previous <literal>testing</literal> transition is taken into account.  Those
2213  during a freeze, or testing transitions may be switched off altogether;  delays may be doubled during a freeze, or <literal>testing</literal>
2214    transitions may be switched off altogether;
2215  </para>  </para>
2216  </listitem>  </listitem>
2217  <listitem>  <listitem>
# Line 2216  available in <literal>unstable</literal> Line 2224  available in <literal>unstable</literal>
2224  <listitem>  <listitem>
2225  <para>  <para>
2226  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
2227  in unstable.  <xref linkend="madison"/> may be of interest to check that  in <literal>unstable</literal>.  <xref linkend="madison"/> may be of interest
2228  information;  to check that information;
2229  </para>  </para>
2230  </listitem>  </listitem>
2231  <listitem>  <listitem>
# Line 2236  all the necessary criteria); Line 2244  all the necessary criteria);
2244  </listitem>  </listitem>
2245  </itemizedlist>  </itemizedlist>
2246  <para>  <para>
2247  To find out whether a package is progressing into testing or not, see the  To find out whether a package is progressing into <literal>testing</literal>
2248  testing script output on the <ulink  or not, see the <literal>testing</literal> script output on the <ulink
2249  url="&url-testing-maint;">web page of the testing  url="&url-testing-maint;">web page of the testing
2250  distribution</ulink>, or use the program <command>grep-excuses</command> which  distribution</ulink>, or use the program <command>grep-excuses</command> which
2251  is in the <systemitem role="package">devscripts</systemitem> package.  This  is in the <systemitem role="package">devscripts</systemitem> package.  This
# Line 2267  shows build dependencies which are not c Line 2275  shows build dependencies which are not c
2275  <title>out-of-date</title>  <title>out-of-date</title>
2276  <para>  <para>
2277  <!-- FIXME: better rename this file than document rampant professionalism? -->  <!-- FIXME: better rename this file than document rampant professionalism? -->
2278  For the testing migration script, outdated means: There are different versions  For the <literal>testing</literal> migration script, outdated means: There are
2279  in unstable for the release architectures (except for the architectures in  different versions in <literal>unstable</literal> for the release architectures
2280  fuckedarches; fuckedarches is a list of architectures that don't keep up (in  (except for the architectures in fuckedarches; fuckedarches is a list of
2281  update_out.py), but currently, it's empty).  outdated has nothing whatsoever to  architectures that don't keep up (in <filename>update_out.py</filename>), but
2282  do with the architectures this package has in testing.  currently, it's empty).  outdated has nothing whatsoever to do with the
2283    architectures this package has in <literal>testing</literal>.
2284  </para>  </para>
2285  <para>  <para>
2286  Consider this example:  Consider this example:
# Line 2300  Consider this example: Line 2309  Consider this example:
2309  </tgroup>  </tgroup>
2310  </informaltable>  </informaltable>
2311  <para>  <para>
2312  The package is out of date on alpha in unstable, and will not go to testing.  The package is out of date on alpha in <literal>unstable</literal>, and will
2313  And removing foo from testing would not help at all, the package is still out  not go to <literal>testing. Removing the package would not help at all, the
2314  of date on alpha, and will not propagate to testing.  package is still out of date on <literal>alpha</literal>, and will not
2315    propagate to testing.
2316  </para>  </para>
2317  <para>  <para>
2318  However, if ftp-master removes a package in unstable (here on arm):  However, if ftp-master removes a package in <literal>unstable</literal> (here
2319    on <literal>arm</literal>):
2320  </para>  </para>
2321  <informaltable pgwide="1">  <informaltable pgwide="1">
2322  <tgroup cols="4">  <tgroup cols="4">
# Line 2335  However, if ftp-master removes a package Line 2346  However, if ftp-master removes a package
2346  </informaltable>  </informaltable>
2347  <para>  <para>
2348  In this case, the package is up to date on all release architectures in  In this case, the package is up to date on all release architectures in
2349  unstable (and the extra hurd-i386 doesn't matter, as it's not a release  <literal>unstable</literal> (and the extra <literal>hurd-i386</literal>
2350  architecture).  doesn't matter, as it's not a release architecture).
2351  </para>  </para>
2352  <para>  <para>
2353  Sometimes, the question is raised if it is possible to allow packages in that  Sometimes, the question is raised if it is possible to allow packages in that
# Line 2355  with the new version of <literal>b</lite Line 2366  with the new version of <literal>b</lite
2366  be removed to allow <literal>b</literal> in.  be removed to allow <literal>b</literal> in.
2367  </para>  </para>
2368  <para>  <para>
2369  Of course, there is another reason to remove a package from testing: It's just  Of course, there is another reason to remove a package from <literal>testing
2370  too buggy (and having a single RC-bug is enough to be in this state).  </literal>: It's just too buggy (and having a single RC-bug is enough to be
2371    in this state).
2372  </para>  </para>
2373  <para>  <para>
2374  Furthermore, if a package has been removed from unstable, and no package in  Furthermore, if a package has been removed from <literal>unstable</literal>,
2375  testing depends on it any more, then it will automatically be removed.  and no package in <literal>testing</literal> depends on it any more, then it
2376    will automatically be removed.
2377  </para>  </para>
2378  </section>  </section>
2379    
# Line 2411  happens to one of your packages. Line 2424  happens to one of your packages.
2424  <section id="s5.13.2.4">  <section id="s5.13.2.4">
2425  <title>influence of package in testing</title>  <title>influence of package in testing</title>
2426  <para>  <para>
2427  Generally, there is nothing that the status of a package in testing means for  Generally, there is nothing that the status of a package in <literal>testing
2428  transition of the next version from unstable to testing, with two exceptions:  </literal> means for transition of the next version from <literal>unstable
2429    </literal> to <literal>testing</literal>, with two exceptions:
2430  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
2431  RC-buggy.  The second exception is if the version of the package in testing is  RC-buggy.  The second exception is if the version of the package in <literal>
2432  out of sync on the different arches: Then any arch might just upgrade to the  testing</literal> is out of sync on the different arches: Then any arch might
2433  version of the source package; however, this can happen only if the package was  just upgrade to the version of the source package; however, this can happen
2434  previously forced through, the arch is in fuckedarches, or there was no binary  only if the package was previously forced through, the arch is in fuckedarches,
2435  package of that arch present in unstable at all during the testing migration.  or there was no binary package of that arch present in <literal>unstable
2436    </literal> at all during the <literal>testing</literal> migration.
2437  </para>  </para>
2438  <para>  <para>
2439  In summary this means: The only influence that a package being in testing has  In summary this means: The only influence that a package being in <literal>
2440  on a new version of the same package is that the new version might go in  testing</literal> has on a new version of the same package is that the new
2441  easier.  version might go in easier.
2442  </para>  </para>
2443  </section>  </section>
2444    
# Line 2442  part of britney.) (There is a similar th Line 2457  part of britney.) (There is a similar th
2457  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.)
2458  </para>  </para>
2459  <para>  <para>
2460  Now, the more complex part happens: Britney tries to update testing with the  Now, the more complex part happens: Britney tries to update <literal>testing
2461  valid candidates; first, each package alone, and then larger and even larger  </literal> with the valid candidates; first, each package alone, and then
2462  sets of packages together.  Each try is accepted if testing is not more  larger and even larger sets of packages together.  Each try is accepted if
2463  uninstallable after the update than before.  (Before and after this part, some  <literal>testing</literal> is not more uninstallable after the update than
2464  hints are processed; but as only release masters can hint, this is probably not  before.  (Before and after this part, some hints are processed; but as only
2465  so important for you.)  release masters can hint, this is probably not so important for you.)
2466  </para>  </para>
2467  <para>  <para>
2468  If you want to see more details, you can look it up on  If you want to see more details, you can look it up on
2469  merkel:/org/&ftp-debian-org;/testing/update_out/ (or there in  <filename>merkel:/org/&ftp-debian-org;/testing/update_out/</filename> (or
2470  ~aba/testing/update_out to see a setup with a smaller packages file).  Via web,  in <filename>merkel:~aba/testing/update_out</filename> to see a setup with
2471  it's at <ulink  a smaller packages file).  Via web, it's at <ulink
2472  url="http://&ftp-master-host;/testing/update_out_code/"></ulink>  url="http://&ftp-master-host;/testing/update_out_code/"></ulink>
2473  </para>  </para>
2474  <para>  <para>
# Line 2467  url="http://&ftp-master-host;/testing/hi Line 2482  url="http://&ftp-master-host;/testing/hi
2482  <section id="t-p-u">  <section id="t-p-u">
2483  <title>Direct updates to testing</title>  <title>Direct updates to testing</title>
2484  <para>  <para>
2485  The testing distribution is fed with packages from unstable according to the  The <literal>testing</literal> distribution is fed with packages from
2486  rules explained above.  However, in some cases, it is necessary to upload  <literal>unstable</literal> according to the rules explained above.  However,
2487  packages built only for testing.  For that, you may want to upload to  in some cases, it is necessary to upload packages built only for <literal>
2488  <literal>testing-proposed-updates</literal>.  testing</literal>.  For that, you may want to upload to <literal>
2489    testing-proposed-updates</literal>.
2490  </para>  </para>
2491  <para>  <para>
2492  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 2482  give on &email-debian-devel-announce;. Line 2498  give on &email-debian-devel-announce;.
2498  <para>  <para>
2499  You should not upload to <literal>testing-proposed-updates</literal> when you  You should not upload to <literal>testing-proposed-updates</literal> when you
2500  can update your packages through <literal>unstable</literal>.  If you can't  can update your packages through <literal>unstable</literal>.  If you can't
2501  (for example because you have a newer development version in unstable), you may  (for example because you have a newer development version in <literal>unstable
2502  use this facility, but it is recommended that you ask for authorization from  </literal>), you may use this facility, but it is recommended that you ask for
2503  the release manager first.  Even if a package is frozen, updates through  authorization from the release manager first.  Even if a package is frozen,
2504  unstable are possible, if the upload via unstable does not pull in any new  updates through <literal>unstable</literal> are possible, if the upload via
2505  dependencies.  <literal>unstable</literal> does not pull in any new dependencies.
2506  </para>  </para>
2507  <para>  <para>
2508  Version numbers are usually selected by adding the codename of the testing  Version numbers are usually selected by adding the codename of the
2509  distribution and a running number, like 1.2sarge1 for the first upload through  <literal>testing</literal> distribution and a running number, like
2510  <literal>testing-proposed-updates</literal> of package version 1.2.  <literal>1.2sarge1</literal> for the first upload through
2511    <literal>testing-proposed-updates</literal> of package version
2512    <literal>1.2</literal>.
2513  </para>  </para>
2514  <para>  <para>
2515  Please make sure you didn't miss any of these items in your upload:  Please make sure you didn't miss any of these items in your upload:
# Line 2500  Please make sure you didn't miss any of Line 2518  Please make sure you didn't miss any of
2518  <listitem>  <listitem>
2519  <para>  <para>
2520  Make sure that your package really needs to go through  Make sure that your package really needs to go through
2521  <literal>testing-proposed-updates</literal>, and can't go through unstable;  <literal>testing-proposed-updates</literal>, and can't go through <literal>
2522    unstable</literal>;
2523  </para>  </para>
2524  </listitem>  </listitem>
2525  <listitem>  <listitem>
# Line 2551  currently, these are critical, grave, an Line 2570  currently, these are critical, grave, an
2570  </para>  </para>
2571  <para>  <para>
2572  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
2573  be released with the stable release of Debian: in general, if a package has  be released with the <literal>stable</literal> release of Debian: in general,
2574  open release-critical bugs filed on it, it won't get into testing, and  if a package has open release-critical bugs filed on it, it won't get into
2575  consequently won't be released in stable.  <literal>testing</literal>, and consequently won't be released in <literal>
2576    stable</literal>.
2577  </para>  </para>
2578  <para>  <para>
2579  The unstable bug count are all release-critical bugs without either any  The <literal>unstable</literal> bug count are all release-critical bugs without
2580  release-tag (such as potato, woody) or with release-tag sid; also, only if they  either any release-tag (such as potato, woody) or with release-tag sid; also,
2581  are neither fixed nor set to sarge-ignore.  The testing bug count for a package  only if they are neither fixed nor set to sarge-ignore.  The <literal>testing
2582  is considered to be roughly the bug count of unstable count at the last point  </literal> bug count for a package is considered to be roughly the bug count of
2583  when the testing version equalled the unstable version.  <literal>unstable</literal> count at the last point when the <literal>testing
2584    </literal>version equalled the <literal>unstable</literal> version.
2585  </para>  </para>
2586  <para>  <para>
2587  This will change post-sarge, as soon as we have versions in the bug tracking  This will change post-sarge, as soon as we have versions in the bug tracking
# Line 2569  system. Line 2590  system.
2590  </section>  </section>
2591    
2592  <section id="s5.13.4.2">  <section id="s5.13.4.2">
2593  <title>How could installing a package into testing possibly break other packages?</title>  <title>How could installing a package into <literal>testing</literal> possibly
2594    break other packages?</title>
2595  <para>  <para>
2596  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
2597  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
2598  package acmefoo is installed into testing, along with its binary packages  package <literal>acmefoo</literal> is installed into <literal>testing</literal>,
2599  acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version  along with its binary packages <literal>acme-foo-bin</literal>, <literal>
2600  is removed.  acme-bar-bin</literal>, <literal>libacme-foo1</literal> and <literal>
2601    libacme-foo-dev</literal>, the old version is removed.
2602  </para>  </para>
2603  <para>  <para>
2604  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
2605  of a library, such as libacme-foo0.  Removing the old acmefoo will remove  of a library, such as <literal>libacme-foo0</literal>.  Removing the old
2606  libacme-foo0, which will break any packages which depend on it.  <literal>acmefoo</literal> will remove <literal>libacme-foo0</literal>, which
2607    will break any packages which depend on it.
2608  </para>  </para>
2609  <para>  <para>
2610  Evidently, this mainly affects packages which provide changing sets of binary  Evidently, this mainly affects packages which provide changing sets of binary
# Line 2592  the ==, &lt;=, or &lt;&lt; varieties. Line 2616  the ==, &lt;=, or &lt;&lt; varieties.
2616  When the set of binary packages provided by a source package change in this  When the set of binary packages provided by a source package change in this
2617  way, all the packages that depended on the old binaries will have to be updated  way, all the packages that depended on the old binaries will have to be updated
2618  to depend on the new binaries instead.  Because installing such a source  to depend on the new binaries instead.  Because installing such a source
2619  package into testing breaks all the packages that depended on it in testing,  package into <literal>testing</literal> breaks all the packages that depended on
2620    it in <literal>testing</literal>,
2621  some care has to be taken now: all the depending packages must be updated and  some care has to be taken now: all the depending packages must be updated and
2622  ready to be installed themselves so that they won't be broken, and, once  ready to be installed themselves so that they won't be broken, and, once
2623  everything is ready, manual intervention by the release manager or an assistant  everything is ready, manual intervention by the release manager or an assistant
# Line 2600  is normally required. Line 2625  is normally required.
2625  </para>  </para>
2626  <para>  <para>
2627  If you are having problems with complicated groups of packages like this,  If you are having problems with complicated groups of packages like this,
2628  contact debian-devel or debian-release for help.  contact &email-debian-devel; or &email-debian-release; for help.
2629  </para>  </para>
2630  </section>  </section>
2631    
Legend:
Removed from v.5196  
changed lines
  Added in v.5199
  ViewVC Help
Powered by ViewVC 1.1.5