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

actively notifying users of removed packages


I would like to bring up the issue of removed packages.  I think
it is problematic that sometimes packages get removed, with no
automatic transition [a transitional package, or another package
depending on a replacement package or conflicting with the old
one], and no active notification to the user.

My primary concern is security.  I recently discovered many
packages that have been removed from Debian, that I had still been
using with no idea that they were removed.  The worst part is,
some of these packages were removed due to outstanding security
bugs!  For example, bitchx and dhcp-client.  It's clear to me that
a silent removal is problematic since the result is existing users
keep that buggy version forever.

An example of a package with a logical replacement is
beep-media-player.  I've been using this program without realizing
that audacious has superceded it.  I would have been nice, though
not necessarily security-critical, to know about
beep-media-player's removal.  Some of the ones I've noticed are a
single binary package removed where the source package still
exists, e.g. hal-device-manager (which is somewhat superceded by
gnome-device-manager).  With ntp-simple, I don't know how, but I
had both ntp and ntp-simple (version 1:4.2.2.p4+dfsg-2) installed,
where ntp presumably was supposed to get rid of ntp-simple.
Apparently a transitional package existed and was subsequently
removed, so it fell through the cracks.

[How to find out why a particular package no longer exists wasn't
obvious either.  A general search via Google or newsgroups usually
doesn't yield anything useful; the way I've figured out how to do
it is (1) look up the package in packages.qa.debian.org, (2) find
a "removed from unstable" message, and (3) look up the associated
bug report at bugs.debian.org.]

Solutions?: Since in many of these situations there may be more
than one replacement or no replacement, it makes sense that
there's no automatic action via a dist-upgrade.

One idea is to have a system where the user is notified when
installed packages no longer exist in the apt repositories, with
an explanation and suggested followups [e.g. install one of X,Y,Z,
or just remove the package].  The default explanation could be
just a link to the BTS page, so no extra required work for

How?  Since users may have installed .deb files manually or
removed lines from /etc/apt/sources.list, the existence of a
package without an apt source isn't necessarily a problem.
However, an active removal via an ftp.debian.org bug, or a source
package no longer building a binary package, is more significant.
I suggest in these cases that when the user runs apt-get upgrade,
he is notified of removed packages (the first time this is
noticed).  This might be implemented in a separate tool hooked in
similar to apt-listchanges, or integrated into apt-get and/or
various frontends; the information might be part of Packages.gz or
a separate file similar to ftp-master.debian.org/removals.txt.  (I
noticed that removals.txt only has a few months of data.  The
mechanism for this idea should allow for people who only run
apt-get once every couple months.)

Thoughts?  What have I missed?  Existing solutions or non-problem?
How can we move towards implementing something like this?  What
other ideas are there for dealing with disappearing packages?


Reply to: