Proposed SRU policy amendment for package removals

[Martin Pitt]

Hello Chuck,

Chuck Peters [2014-11-12  3:25 +0000]:
> Both tor and owncloud are recurring examples!

tor was reintroduced explicitly two years after the removal
(https://launchpad.net/bugs/413657). If that is out of date again and
unmaintained, we should remove it again and blacklist it this time so
that it doesn't come back automatically. If that's the case, then I
suggest filing a new removal/SRU bug for this.

owncloud isn't a recurring example; it was removed now and
blacklisted.

> If we just make an empty package that gives the user some direction
> on installing upstream, why don't we just do it for them

This is *exclusively* a crutch for stable releases to "override" an
undeletable package in a stable release. In the devel series (and
hence in all future stable disto releases) the package should be
removed completely. We don't want "installer" packages for free
software in the archive by policy.

> Furthermore amending the SRU process as proposed doesn't really
> address the fundamental issue of universe packages are often not
> maintained and with something like tor the consequences can be very
> dangerous.

Right, that's why we are drafting this policy now so that we don't
start from scratch every time :-) But in reality most unmaintained
universe packages are by far not as dangerous as tor.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)