1464
Comment: Stick in some text that should make an ok starting point
|
2015
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
= Package removal requests = == Do you need to request removal? == == Removals from testing, stable and oldstable == == Before requesting removal == == 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 == Wibble == |
Package removal requests
Do you need to request removal?
Removals from testing, stable and oldstable
Before requesting removal
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
Wibble
> is there a comprehensive list of how to title requests against > ftp.debian.org? Perhaps we could make one on wiki.debian.org
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