On Thu, 2012-08-16 at 18:35 +0300, Antti-Juhani Kaijanaho wrote: > Perhaps there should be a note making clear that only removal from unstable > (and experimental) is what is meant here; removals from testing do not give > cause to use this procedure.
I changed the sentence to make it clear that this is only triggered by removals from unstable. Updated patch attached. -- bye, pabs http://wiki.debian.org/PaulWise
Index: pkgs.dbk =================================================================== --- pkgs.dbk (revision 9307) +++ pkgs.dbk (working copy) @@ -1238,7 +1238,7 @@ </section> <section id="archive-manip"> -<title>Moving, removing, renaming, adopting, and orphaning packages</title> +<title>Moving, removing, reintroducing, renaming, adopting, and orphaning packages</title> <para> Some archive manipulation operations are not automated in the Debian upload process. These procedures should be manually followed by maintainers. This @@ -1385,6 +1385,49 @@ </section> +<section id="reintroducing-pkgs"> +<title>Reintroducing packages</title> +<para> +Packages are often removed due to release-critical bugs, absent maintainers, +too few users or poor quality in general. There are some things you should be +aware of when reintroducing removed packages. +</para> +<para> +You should check why the package was removed in the first place. This +information can be found in the removal item in the news section of the PTS +page for the package or by browsing the log of +<ulink url="http://&ftp-master-host;/removals.html";>removals</ulink>. +The removal bug will tell you why the package was removed and will give some +indication of what you will need to work on in order to reintroduce the package. +It may indicate that the best way forward is to switch to some other piece of +software instead of reintroducing the package. +</para> +<para> +It may be appropriate to contact the former maintainers to find out if +they are working on reintroducing the package, interested in co-maintaining +the package or interested in sponsoring the package if needed. +You should do all the things required before introducing new packages +(<xref linkend="newpackage"/>). +</para> +<para> +You should base your work on the latest packaging available that is suitable. +That might be the latest version from <literal>unstable</literal>, which will +still be present in the <ulink url="&snap-debian-org;">snapshot archive</ulink>. +Or the version control system used by the previous maintainer might contain +newer packaging. Check if the control file of the previous package contained +any headers linking to the version control system for the package and if it +still exists. +</para> +<para> +Package removals from unstable (not testing, stable or oldstable) trigger the +closing of all bugs related to the package. You should look through all the +closed bugs (including archived bugs) and unarchive and reopen any that were +closed in a version ending in <literal>+rm</literal> and still apply. Any that +no longer apply should be marked as fixed in the correct version if that is +known. +</para> +</section> + <section id="s5.9.3"> <title>Replacing or renaming packages</title> <para> Index: common.ent =================================================================== --- common.ent (revision 9307) +++ common.ent (working copy) @@ -28,6 +28,7 @@ <!ENTITY www-debian-org "www.debian.org"> <!ENTITY ftp-debian-org "ftp.debian.org"> <!ENTITY release-debian-org "release.debian.org"> +<!ENTITY snap-debian-org "snapshot.debian.org"> <!ENTITY lists-host "lists.debian.org"> <!ENTITY archive-host "archive.debian.org"> <!ENTITY keyserver-host "keyring.debian.org">
signature.asc
Description: This is a digitally signed message part
