Re: Proposed SRU policy amendment for package removals
Hey Kees, Kees Cook [2014-11-11 9:13 -0800]: FTR, this proposal now lives on https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves for easier editing (already did a typo and a grammar update suggested by Robbie, thanks!) I like it, thanks! Is it worth maintaining the explicit list of removals (more than just Examples:)? Yes, I think it is, there won't be too many of those. I adjusted the wiki page accordingly. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Hello Chuck, Chuck Peters [2014-11-12 3:25 +]: 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) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
Martin, On 2014-11-12 05:43 AM, Martin Pitt wrote: Hello Chuck, Chuck Peters [2014-11-12 3:25 +]: 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. Perhaps blacklisting for new releases by default should be added to the procedure? We can always remove a package from the blacklist if someone steps up and volunteers to support it. Marc. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Proposed SRU policy amendment for package removals
On Wed, Nov 12, 2014 at 07:53:13AM -0500, Marc Deslauriers wrote: On 2014-11-12 05:43 AM, Martin Pitt wrote: Chuck Peters [2014-11-12 3:25 +]: 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. Perhaps blacklisting for new releases by default should be added to the procedure? We can always remove a package from the blacklist if someone steps up and volunteers to support it. If a package has previously been in Ubuntu and has been removed, then it won't be auto-synced (although it will show up in the output of auto-sync for manual resolution; currently only I see that). It normally isn't necessary these days to preemptively blacklist things when you remove them. If a package actually reappears, it might still be worthwhile to blacklist it then in order to quieten auto-sync, but you don't need to do that preemptively. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
