Differences between revisions 5 and 6
Revision 5 as of 2006-08-02 19:58:15
Size: 3786
Editor: AdamBarratt
Comment: More fleshing
Revision 6 as of 2006-08-15 17:43:56
Size: 5688
Editor: AdamBarratt
Comment: Add examples and "who are you?" section
Deletions are marked like this. Additions are marked like this.
Line 39: Line 39:
=== Who are you? ===

The ftp-masters will need to know your relationship to the package (if any) in order to process your request. In most cases, they will expect the request to be made by the maintainer (including co-maintainers) although there are a number of other parties who might be expected to submit removal requests for various reasons:

 * Porters requesting removal of binaries for their architecture
 * The Release Managers or Stable Release Managers, for packages which they do not consider to be suitable for release or which should be removed from stable (although the latter happens very rarely)
 * The QA team. Normally this will involve orphaned packages and/or MIA maintainers

If you do not fall in to any of the categories listed, you should indicate in your report why you are requesting that the package be removed.
Line 54: Line 64:

=== Examples ===

The m68k porters request that bigpackage's m68k binaries be removed as they do not build

  '''RM: bigpackage [m68k] -- RoP; FTFBS'''

The binary package foobar is no longer built on hppa, but packages from an earlier version are still present in unstable. If a version of the package built on hppa is present in testing, this will stop the new version of foobar entering testing due to the "missing" hppa binaries.

  '''RM: foobar [hppa] -- RoM; ANAIS'''

ANAIS may also be used in situations where a binary package has been uploaded for an architecture which is not listed in the package's control file. This should only occur if, for example, the package was built and uploaded by neither the maintainer nor an official auto-builder.

Package wibble is orphaned, has release critical bugs and appears to have been abandoned upstream. In this case the package has never been part of a Debian release and the QA team request its removal.

  '''RM: wibble -- RoQA; orphaned; NPOASR; RC-buggy; abandoned upstream'''

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)

Who are you?

The ftp-masters will need to know your relationship to the package (if any) in order to process your request. In most cases, they will expect the request to be made by the maintainer (including co-maintainers) although there are a number of other parties who might be expected to submit removal requests for various reasons:

  • Porters requesting removal of binaries for their architecture
  • The Release Managers or Stable Release Managers, for packages which they do not consider to be suitable for release or which should be removed from stable (although the latter happens very rarely)
  • The QA team. Normally this will involve orphaned packages and/or MIA maintainers

If you do not fall in to any of the categories listed, you should indicate in your report why you are requesting that the package be removed.

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.

Examples

The m68k porters request that bigpackage's m68k binaries be removed as they do not build

  • RM: bigpackage [m68k] -- RoP; FTFBS

The binary package foobar is no longer built on hppa, but packages from an earlier version are still present in unstable. If a version of the package built on hppa is present in testing, this will stop the new version of foobar entering testing due to the "missing" hppa binaries.

  • RM: foobar [hppa] -- RoM; ANAIS

ANAIS may also be used in situations where a binary package has been uploaded for an architecture which is not listed in the package's control file. This should only occur if, for example, the package was built and uploaded by neither the maintainer nor an official auto-builder.

Package wibble is orphaned, has release critical bugs and appears to have been abandoned upstream. In this case the package has never been part of a Debian release and the QA team request its removal.

  • RM: wibble -- RoQA; orphaned; NPOASR; RC-buggy; abandoned upstream