actively notifying users of removed packages
Hi, 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 maintainers. 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? Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
On 2008-03-11 06:52 PDT, Lucas Nussbaum writes:
Lucas If you are only interested in a few packages, you could
Lucas subscribe to them on the PTS. I recently worked on a
Lucas script to notify PTS subscribers ('summary' keyword)
Lucas when the package is orphaned or removed. (see
Lucas #464021)
On 2008-03-11 06:57 PDT, Andreas Bombe writes:
Andreas It's no active notification, but aptitude lists all
Andreas installed packages that aren't in any distribution
Andreas included in sources.list under Obsolete and Locally
Andreas Created Packages. Verifying that this doesn't
Andreas include any packages that I expect there (like
Andreas locally compiled kernel module packages) is my way of
Andreas checking for removed packages.
Good points, I also discovered Synaptic works well for manually
looking for removed packages. Notifying PTS subscribers by email
also sounds very useful. Still, I worry about the people who
don't know to check for removed packages - and aren't watching
the packages that happened to be removed.
Karl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition, LVM, and RAID management utility
On 2005-08-10 17:06 PDT, Shaun Jackman writes: Shaun My sense of it is that there isn't a tool packaged in Shaun Debian to fill this need -- although feel free to give Shaun suggestions at this point. Evms is the best all-in-one tool for disk management I've found. However, Debian-Installer doesn't support it, and you need to patch the kernel to be able to use evms with non-evms partitions on the same disk. I don't think initrd-tools supports it either, so using evms for the root partition is also tricky. If the default kernel image included the bd-claim patch, things would be a lot easier. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304507 -- Karl 2005-08-10 18:49 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is it a bug to not depend on a library package needed for some binary?
On 2005-07-17 14:00 PDT, Matthew Woodcraft writes: Matthew There is a lot of discussion of this question in bug Matthew 119517 (where the conclusion reached was that this is Matthew sometimes ok). Wow, that was a long thread. Thanks for the pointer. I will file bugs if it there is no Recommends/Suggests and/or I can't find previous discussion of the issue. -- Karl 2005-07-18 12:46 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
is it a bug to not depend on a library package needed for some binary?
Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1 is the important program, and B2 is not as important. Is it OK for the declared package dependencies to not satisfy all the run-time shared library dependencies of B2? What if they are listed in Suggests? I have found many such packages. -- Karl 2005-07-17 01:09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
On 2005-03-23 01:17 PST, Frank Kster writes: fant What do you do to look at the differences? I'm just doing a diff between the list of files produced (the thing I'm doing changes compiled output files anyway) - so timestamps shouldn't affect anything. Some of them just produce different number of 'info' files; but some actually differ in programs in /usr/bin. I think that should be consistent at least. If I see something like a program missing from /usr/bin, is it worth investigating and filing a bug? -- Karl 2005-03-23 11:22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
On 2005-03-22 20:13 PST, Jeroen van Wolffelaar writes: Jeroen I think it'd be good to ship sarge without such Jeroen situations, but again, this needs to be looked into on Jeroen a case-by-case basis, and I certainly dare not say Jeroen that every such case must be a bug (but I suspect so Jeroen in general). Source packages readline4 and readline5 both produce binary rlfe. What do you think about this situation? -- Karl 2005-03-23 11:24 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
On 2005-03-23 16:33 PST, Jeroen van Wolffelaar writes: I didn't know about debdiff - that would have saved me from basically re-implementing it. Jeroen Common problem unfortunately in the open source/Debian Jeroen world... not that $what_you_want doesn't exist, but Jeroen that you just don't know it exists nor where to find Jeroen it :(. Well - since I need fine control (such as being able to ignore certain minor differences) - and it was only a couple lines of code - I didn't even bother looking for it. -- Karl 2005-03-23 16:42 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
On 2005-03-23 11:44 PST, Jeroen van Wolffelaar writes: Jeroen I assume you use 'debdiff' that actually does those Jeroen list you the differences in file lists? And also Jeroen differences in dependencies, if a recompile introduces Jeroen another dependency, it is worth fixing this now, Jeroen because after sarge is released, this might cause Jeroen problems in the future with security updates. I didn't know about debdiff - that would have saved me from basically re-implementing it. -- Karl 2005-03-23 16:25 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
discrepancies between uploaded and source-built .deb
Hi, I'm doing something that involves building every Debian package, and I'm finding (usually minor) discrepancies between what I build from source packages, and the binary packages uploaded by maintainers. I'm building each package in its own chroot which contains only the minimum packages (bootstrap + build-essential + build-dependencies). Are such things considered bugs? Also, what is the policy on the relationship between source packages and binary packages. May two source package both produce the same binary package? -- Karl 2005-03-22 18:24 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
