Differences between revisions 4 and 5
Revision 4 as of 2006-08-01 10:26:37
Size: 2906
Editor: AdamBarratt
Comment: Flesh out
Revision 5 as of 2006-08-02 19:58:15
Size: 3786
Editor: AdamBarratt
Comment: More fleshing
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
As part of their archive maintenance role, the ftp-master team periodically (usually every few days) run a tool which searches for packages that should be removed. This tool used to be known as "rene" (and is still often referred to as such) but has now become the "auto-cruft" sub-command of dak. As part of their archive maintenance role, the ftp-master team periodically (usually every few days) run a tool which searches for packages that should be removed. This tool used to be known as "rene" (and is still often referred to as such) but has now become the "auto-cruft" sub-command of dak. In the cases handled by this tool, there is no need to request that your package be removed.

You can view a recent copy of the tool's output at [http://ftp-master.debian.org/~jeroen/rene-full.txt]. The most common cases that are handled by the tool are:

 * Binary packages no longer built from any source package ("NBS", i.e. "not built from source")
 * Source packages which have had all their binary packages taken over by another source packages ("obsolete source packages")
 * Packages in experimental for which a higher numbered version of the package exists in unstable ("NVIU" - "newer version in unstable")
 * Packages in testing-proposed-updates for which a higher numbered version exists in testing ("NVIT")
Line 14: Line 21:
|| [http://www.debian.org/releases/testing testing] || Release Managers [[mailto:debian-release@lists.debian.org debian-release@lists.debian.org]] ||
|| [http://www.debian.org/releases/stable stable] || Stable Release Managers [[mailto:debian-release@lists.debian.org debian-release@lists.debian.org]] ||
|| [http://www.debian.org/releases/testing testing] || Release Managers [mailto:debian-release@lists.debian.org debian-release@lists.debian.org] ||
|| [http://www.debian.org/releases/stable stable] || Stable Release Managers [mailto:debian-release@lists.debian.org debian-release@lists.debian.org] ||
Line 21: Line 28:
=== Reverse Dependencies ===
Line 22: Line 30:
If your package has reverse dependencies in unstable, you need to ensure that they are aware of your intention to remove the package. Where possible, this will include suggesting (either via bugs or direct contact with the maintainer) a means of the dependent package handling the removal.

For instance, if you are removing an obsolete version of a library that the dependent package is still using, you should suggest that they transition to the current version.


If you are a DD, you can execute the folllowing command on merkel to check your package's reverse dependencies:

''dak rm -Rn $PACKAGE'' (or ''melanie -Rn $PACKAGE'' if the former doesn't work)
Line 27: Line 43:
The subject line of the bug report The subject line of the bug report should be in the format
Line 29: Line 45:
== Wibble ==   RM: $PACKAGE [$ARCHITECTURES] -- $REASONS
Line 31: Line 47:
> is there a comprehensive list of how to title requests against
> ftp.debian.org? Perhaps we could make one on wiki.debian.org
where
Line 34: Line 49:
It's one of those things that nobody seems to have found the appropriate
tuits for. I think about doing it every so often but then get distracted;
Jeroen has talked about documenting the format in the past (hence the Cc).
I'm also not entirely sure whether such documentation belongs somewhere more
"official" (e.g. 5.9.2 of the Developer's Reference) as there's more
information that should probably be written down somewhere relating to
removals - e.g. "if the package is still listed in debian/control then
you'll just get the bug reassigned to the package, requesting that gets
fixed first".

Likewise, the DevRef section might want to expand on the comments on
"testing" removal (as there's no point asking ftpmaster for such removals)
and a mention of "rene" so that maintainers know they don't need to request
removals for source packages no longer building any binaries, etc.

The syntax is basically

  RM: <source package> <architecture> -- <reasons>

where:

  <architecture> is of the form "[arch(| arch)*]" and should be omitted
unless
  you're requesting a partial removal (i.e. only removing the binaries for
some
  architectures, as in this case)

and

  <reasons> approximately corresponds to the list at the head of
  http://ftp-master.debian.org/removals.txt, plus comments

Adam
 * $PACKAGE is the source package in most cases; if requesting the removal of specific binary packages they should be listed here instead.
  * If you are requesting removal of packages from experimental, this should be indicated in the form $PACKAGE/experimental.
 * $ARCHITECTURES is only needed if requesting that only some architectures' packages be removed. If specified, the list should be in the same format as that used by dpkg - i.e. a space-separated list surrounded by brackets.
 * $REASONS approximately corresponds to the list at the head of http://ftp-master.debian.org/removals.txt, plus comments.
  * The first entry in the list of reasons should indicate the position from which you are requesting the removal - e.g. RoM if you are the maintainer, RoP if you are a porter requesting removal of packages for your architecture, and so on.

Package removal requests

Do you need to request removal?

As part of their archive maintenance role, the ftp-master team periodically (usually every few days) run a tool which searches for packages that should be removed. This tool used to be known as "rene" (and is still often referred to as such) but has now become the "auto-cruft" sub-command of dak. In the cases handled by this tool, there is no need to request that your package be removed.

You can view a recent copy of the tool's output at [http://ftp-master.debian.org/~jeroen/rene-full.txt]. The most common cases that are handled by the tool are:

  • Binary packages no longer built from any source package ("NBS", i.e. "not built from source")
  • Source packages which have had all their binary packages taken over by another source packages ("obsolete source packages")
  • Packages in experimental for which a higher numbered version of the package exists in unstable ("NVIU" - "newer version in unstable")
  • Packages in testing-proposed-updates for which a higher numbered version exists in testing ("NVIT")

Removals from testing, stable and oldstable

The ftp-master team only process removals from the unstable and experimental distributions.

The table below summarises the relevant contact points for requesting removals from other distributions.

Distribution

Contact

[http://www.debian.org/releases/testing testing]

Release Managers [mailto:debian-release@lists.debian.org debian-release@lists.debian.org]

[http://www.debian.org/releases/stable stable]

Stable Release Managers [mailto:debian-release@lists.debian.org debian-release@lists.debian.org]

oldstable

Not possible

Before requesting removal

Reverse Dependencies

If your package has reverse dependencies in unstable, you need to ensure that they are aware of your intention to remove the package. Where possible, this will include suggesting (either via bugs or direct contact with the maintainer) a means of the dependent package handling the removal.

For instance, if you are removing an obsolete version of a library that the dependent package is still using, you should suggest that they transition to the current version.

If you are a DD, you can execute the folllowing command on merkel to check your package's reverse dependencies:

dak rm -Rn $PACKAGE (or melanie -Rn $PACKAGE if the former doesn't work)

How to request removal

File a bug against the [http://bugs.debian.org/ftp.debian.org ftp.debian.org pseudo-package]. The ftp-masters do not take account of the severity of the bug reported when processing removals, so if you believe the request to be "important" then simply provide appropriate reasoning in the report.

The subject line of the bug report should be in the format

  • RM: $PACKAGE [$ARCHITECTURES] -- $REASONS

where

  • $PACKAGE is the source package in most cases; if requesting the removal of specific binary packages they should be listed here instead.
    • If you are requesting removal of packages from experimental, this should be indicated in the form $PACKAGE/experimental.
  • $ARCHITECTURES is only needed if requesting that only some architectures' packages be removed. If specified, the list should be in the same format as that used by dpkg - i.e. a space-separated list surrounded by brackets.
  • $REASONS approximately corresponds to the list at the head of http://ftp-master.debian.org/removals.txt, plus comments.

    • The first entry in the list of reasons should indicate the position from which you are requesting the removal - e.g. RoM if you are the maintainer, RoP if you are a porter requesting removal of packages for your architecture, and so on.