[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: