Differences between revisions 26 and 27
Revision 26 as of 2008-04-17 17:56:08
Size: 9293
Editor: AdamBarratt
Comment: Tweak oldstable/stable/testing section
Revision 27 as of 2008-04-17 18:00:07
Size: 9334
Editor: AdamBarratt
Comment:
Deletions are marked like this. Additions are marked like this.
Line 105: Line 105:
    * [cruft-report] == detected by the cruft finder script 'rene'     * [cruft-report] == detected by the cruft finder script 'rene' (not intended to be used for bug reports)

Package removal requests

Do you need to request removal?

As part of their archive maintenance role, the ftp-master team periodically (daily, cron-job) 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 "cruft-report" sub-command of dak. In the cases handled by this tool, there is no need to request that your package be removed (apart from the "Architecture Not Allowed In Source" case, which still need a removal request).

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")

Removals from testing, stable and oldstable

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

The table below summarises the relevant additional 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

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

To clarify: The Stable Release Team is responsible for preparing and accepting the (old)stable point releases which consist of updating, adding and removing packages (and sometimes updating d-i). The ftp-master team is responsible for actually doing the (old)stable point releases. To ease the work required by the ftp-master team, removal bugs should be filed against ftp.debian.org. To ease the work required by the Stable Release Team they should also be contacted about removals from (old)stable.

There is an exception in the case of per-architecture removals from testing. These are not handled by the Release Managers directly, but rather as a result of the package's state in unstable propagating to testing.

For example, assume that package foobar exists in both testing and unstable for s390 but it has been discovered that, despite building, the binaries do not work on that architecture. In order to get the binary package removed from testing, you need to ensure that it is no longer built in unstable (by e.g. uploading a new version that ftbfs on architectures which are not supported) and then ask the ftp-master team to remove the out-of-date s390 binary package from unstable. Once the package is otherwise ready to transition to testing, the s390 binary in testing will be automatically removed during the transition.

Note that in most cases it is unnecessary to request removal of your package from both testing and unstable. Once the package is removed from unstable, it will automatically be removed from testing once there are no dependencies keeping it there.

If you do need the package simultaneously removed from both distributions, you will need to file a removal bug for unstable as usual, and contact the Release Managers to request removal from testing.

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. The ftp-team usually does not remove a package that still has a reverse dependency.

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 $SOURCEPACKAGE

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. In all cases, if there is a maintainer and it's not you, mention the maintainer's opinion or, if you don't know it, mention how and when you tried to contact him. If you didn't try to contact the maintainer, do so first. One way would be to file the bug as an RC bug on the package first, indicating why you think the package should be removed, and asking the maintainer if he/she agrees with reassigning the bug to ftp.debian.org. If after a few weeks and some prodding there's still no reaction, and you believe the ftp-master team would process the removal anyway despite the maintainer not having replied, you might consider reassigning the bug yourself.

Upgrade path

If you're requesting a removal because of a package rename, give some thought to a proper upgrade path for existing users. Consider building a dummy upgrade pseudo-package from the new, renamed package. For example, 'iceape' in etch also builds dummy 'mozilla', 'mozilla-browser', etc packages. Once such a dummy pseudo-package has appeared in a stable release, you can then simply stop building it and it'll get semi-automatically removed (see above).

If the old name of the package has never appeared in a stable release, it also makes no sense to have it do so; make sure that such dummy packages do not appear in stable releases in this case.

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 and, except in very rare cases (e.g. licensing problems) removals from unstable or experimental are not release critical. Removal bugs should thus be filed as severity "normal"; if you believe the request to be "important" or "serious" then simply provide appropriate reasoning in the report.

The subject line of the bug report should be in the format described in the "About removals in Debian" section at the top of [http://ftp-master.debian.org/removals.html http://ftp-master.debian.org/removals.html].

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 (from source package fizz) is no longer built on hppa and arm, some other binary packages of source fizz are still built there. 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 arm] -- RoM; ANAIS

All binary packages from source package fizz are no longer built on hppa and ia64 and should be removed.

  • RM: fizz [hppa ia64] -- 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 can occur if, for example, the package was built and uploaded by neither the maintainer nor an official auto-builder, or if the list of supported architectures is being reduced.

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

Commonly used acronyms: (taken from http://ftp-master.debian.org/removals.html)

  • ROM == Request Of Maintainer
  • RoQA == Requested by the QA team
  • ROP == Request of Porter
  • ROSRM == Request of Stable Release Manager
  • NBS == Not Built [by] Source
  • NPOASR == Never Part Of A Stable Release
  • NVIU == Newer Version In Unstable
  • ANAIS == Architecture Not Allowed In Source
  • ICE == Internal Compiler Error
  • [cruft-report] == detected by the cruft finder script 'rene' (not intended to be used for bug reports)


CategoryPermalink