Whole document tree
    

Whole document tree

Debian Developer's Reference - Moving, Removing, Renaming, Adopting, and Orphaning Packages
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ next ]

Debian Developer's Reference
Chapter 9 - Moving, Removing, Renaming, Adopting, and Orphaning Packages


Some archive manipulation operation are not automated in the Debian upload process. These procedures should be manually followed by maintainers. This chapter gives guidelines in what to do in these cases.


9.1 Moving packages

Sometimes a package will change its section. For instance, a package from the `non-free' section might be GPL'd in a later version, in which case, the package should be moved to `main' or `contrib'.[1]

If you need to change the section for one of your packages, change the package control information to place the package in the desired section, and re-upload the package (see the Debian Policy Manual for details). Carefully examine the installation log sent to you when the package is installed into the archive. If for some reason the old location of the package remains, file a bug against ftp.debian.org asking that the old location be removed. Give details on what you did, since it might be a bug in the archive maintenance software.

If, on the other hand, you need to change the subsection of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly different. Correct the subsection as found in the control file of the package, and reupload that. Also, you'll need to get the override file updated, as described in The override file, Section 6.7.1.


9.2 Removing packages

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is not longer required), you need to file a bug against ftp.debian.org asking that the package be removed. Make sure you indicate which distribution the package should be removed from.

If in doubt concerning whether a package is disposable, email debian-devel@lists.debian.org asking for opinions. Also of interest is the apt-cache program from the apt package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends.


9.2.1 Removing packages from Incoming

In the past, it was possible to remove packages from incoming. With the introduction of the New Incoming system this is no longer possible. Instead, you have to upload a new revision of your package with a higher version as the package you want to replace. Both versions will be installed in the archive but only the higher version will actually be available in unstable since the previous version will immediately be replaced by the higher. However, if you do proper testing of your packages, the need to replace a package should not occur too often anyway.


9.3 Replacing or renaming packages

Sometimes you made a mistake naming the package and you need to rename it. In this case, you need to follow a two-step process. First, set your debian/control file to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for details). Once you've uploaded that package, and the package has moved into the archive, file a bug against ftp.debian.org asking to remove the package with the obsolete name.


9.4 Orphaning a package

If you can no longer maintain a package, you need to inform the others about that, and see that the package is marked as orphaned. you should set the package maintainer to Debian QA Group <packages@qa.debian.org> and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to normal. If you feel it's necessary, send a copy to debian-devel@lists.debian.org by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).

If the package is especially crucial to Debian, you should instead submit a bug against wnpp and title it RFA: package -- short description and set its severity to important. Definitely copy the message to debian-devel in this case, as described above.

Read instructions on the WNPP web pages for more information.


9.5 Adopting a package

A list of packages in need of a new maintainer is available at in the Work-Needing and Prospective Packages list (WNPP). If you wish to take over maintenance of any of the packages listed in the WNPP, please take a look at the aforementioned page for information and procedures.

It is not OK to simply take over a package that you feel is neglected — that would be package hijacking. You can, of course, contact the current maintainer and ask them if you may take over the package. However, without their assent, you may not take over the package. Even if they ignore you, that is still not grounds to take over a package. If you really feel that a maintainer has gone AWOL (absent without leave), post a query to debian-private@lists.debian.org.

If you take over an old package, you probably want to be listed as the package's official maintainer in the bug system. This will happen automatically once you upload a new version with an updated Maintainer: field, although it can take a few hours after the upload is done. If you do not expect to upload a new version for a while, send an email to override-change@debian.org so that bug reports will go to you right away.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ next ]

Debian Developer's Reference

ver. 2.11, 08 April, 2002
Adam Di Carlo, current maintainer aph@debian.org
Christian Schwarz schwarz@debian.org
Ian Jackson ijackson@gnu.ai.mit.edu