Re: Handling of removed packages
Hello,
On Thu, 2008-05-29 at 14:40 +0200, Kai Wasserbäch wrote:
> Marc 'HE' Brockschmidt schrieb:
> > For some time now, I have been thinking about the problem of packages
> > which are removed from the archive at some point, without an (enforced)
> > transition to a new package name. Users of such packages keep them
> > around, usually never noticing the fact that no security (or other)
> > support is available anymore.
>
> I have somewhat of a deja-vù here with that thread.
> [..] So the solution then was "the user must check aptitudes obsolete
> category".
We might assume that Debian is only used in managed environment, where
system admins actually RTFM.
But if we aim world domination (i.e. reach true end-users), we can't
expect system-owners to actually read the fine manuals. (It's a fact,
right ?).
I wouldn't be comfortable telling my [brother|sister|friend], who's
system would have been compromised due to an obsolete packages, that
it's their fault because they should have checked "obsolete" package, as
explained in the fine manual...
Also, any pop-up/warning based solution will merely lead people to
ignore or disable them.
PROPOSAL : Remove obsolete packages on upgrade :
If we remove a package in a release, there is probably good reason for
that (!). So I tend to think that we should automatically remove the
package during systems upgrades (by default).
One could create dummy transition packages that `provides` the removed
package :
- It could be named like "flashplugin-is-deprecated-in-lenny".
- It's description should have appropriate comments (why was the
package removed).
- It should suggest replacements.
- Such transition package would only be created for package that were
actually in the previous release (i.e not for package that appeared
and disappeared during a given `testing` cycle).
- Those packages might have their own section.
Pros :
- The user could still "Hold" the old package to prevent removal (which
state properly describe the package status).
- The user could still use another [unofficial] apt source, that
actually provide the package, so the package isn't removed.
- Users using lenny that search for a package removed since etch
would actually find it (and know it is in "removed from archive") !
- If a package moves from main to contrib or non-free, we could use the
same transition, so one would know about it
(package named like "foobar-is-now-in-non-free").
- Using package-dependencies means that it would "just work" with any
existing tool.
Cons :
- "One" has to create, maintain (and remove) those packages !
- It uses space in the mirrors.
I gave a try to automatically build such transition package. Currently
that about 460 package (we could merge some of them, like libapache* ).
The source's control would look like :
http://www.klabs.be/~fpiat/linux/debian/proposals/2008-05-30_package-removal/debian/control
Here's the script (very ugly currently).
http://www.klabs.be/~fpiat/linux/debian/proposals/2008-05-30_package-removal/refresh.sh
Any comment ?
Franklin
Reply to: