Drew Engelbrecht wrote: > I've noticed some abandoned configuration files have been left lying around > my harddrive, which by their existence have a (sometimes negative) effect on > my upgraded system. They were installed by packages in lenny, but would not > be installed in a fresh installation of squeeze. Despite unmodified > configuration files getting replaced by newer ones when upgrading, it seems > that if they don't belong to the same package in squeeze as in lenny, then > they are not removed... even though that file may be unmodified from the > original (and now useless or even harmful.) I think this is a prime opportunity for people upgrading to help Debian and to chase down some of those and to file bugs against those packages. Because you are absolutely right that some of those are causing terrible problems. But mostly they are not known and therefore not tracked in the BTS. If we can get those diagnosed and bugs filed then some progress can be made at improving the situation. > For example, there's the /etc/X11/xorg.conf file that dpkg-reconfigure > doesn't change or remove in squeeze (and doesn't add, if there's not one > there.) Some things are going to be problematic. This is one of those. Because in that case any local configuration from the admin would be lost if that file were automatically removed. A working installation that required tweaks would be broken. Many people would have the opposite complaint in that case. This is likely an impossible no-win situation. I didn't look in the upgrade notes to see if this one was mentioned. But I have a memory that it was mentioned there. > Also, there was a file in /etc/udev/rules.d/ for wacom input. Something like > 50 errors would show up when I booted, because of this file. This one has a bug filed against it. People migrating from Lenny to Squeeze may (probably will?) hit it. I hit it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565126 But there hasn't been any movement on it that I can see. An NMU from a DD would be appropriate. > I noticed that using the "loate" command for the xserver-xorg-input-wacom > package listed the problematic rules file, so my system knew that it was > there and associated with the package. I tried purging the wacom package and > reinstalling xserver-xorg-input-all. The file and the problem went away. Yes. Exactly as you said. The best workaround I can suggest is to purge the package, which will also remove the meta package that depends upon it, and then reinstall the dependency meta package. $ dpkg -L xserver-xorg-input-wacom | grep udev/rules.d/ /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules /etc/udev/rules.d/z60_xserver-xorg-input-wacom.rules # apt-get remove --purge xserver-xorg-input-wacom # apt-get install xserver-xorg-input-all $ dpkg -L xserver-xorg-input-wacom | grep udev/rules.d/ /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules > Unfortunately, I don't think that it's feasible to purge and reinstall the > entire installation base though ;-) so I'm still looking for a general > solution. I think this conversation in debian-devel is related. Not exactly. But it is looking at a similar problem space. http://lists.debian.org/debian-devel/2010/12/msg00153.html > Is there a way to remove deprecated files like these automatically? Have you looked at packages that are removed but not purged? dpkg -l | grep ^rc That will identify packages that have been removed but not purged and still have configuration files remaining behind. You could then examine the list and purge those. That will remove the associated configuration files. Might be a useful start. Have you looked at removing dummy and transition packages? dpkg -l | grep -e dummy -e transition Cleaning those would help to keep the system tidy. Although some people think that APT's new autoremove feature will make deborphan obsolete I still find it useful. 'sudo orphaner' or 'sudo orphaner -a' for the full list. (I expect many will reply that aptitude does it better. That's nice. I like deborphan better.) Certainly with autoremove there isn't as much to do there these days. > I'm having some minor issues with squeeze, and I can't help but > wonder if there are still some "zombie" config files that are > creating issues here by making my system less like a clean install > of squeeze. What kinds of problems are you having? On a first pass I would concatenate all of the known conffiles from all installed packages. Then compare that list to the actual list of files in /etc. Any differences would stand out. Let's see: $ cat /var/lib/dpkg/info/*.conffiles > /tmp/conffiles.list $ sort -o /tmp/conffiles.list /tmp/conffiles.list $ sudo find /etc > /tmp/etc.list $ sort -o /tmp/etc.list /tmp/etc.list $ comm -23 /tmp/conffiles.list /tmp/etc.list | less Hmm... There are some files listed as conffiles that don't actually exist on my system. Something to look at more closely later. Not a problem for the moment. $ comm -13 /tmp/conffiles.list /tmp/etc.list | less Oh my goodness there are a lot of untracked files! How many? $ comm -13 /tmp/conffiles.list /tmp/etc.list | wc -l 2300 Wow. Too many to track down by that method. Will have to try something different. If I were really wanting to track this down on my system then I would install a fresh copy of squeeze in a chroot. http://wiki.debian.org/Debootstrap http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292281 I would install a complete system fresh in the chroot. This means there I no need to affect your currently installed system which can be left in place and untouched. Then I would compare the files in the chroot to the files in the live system. They should be the same. Any differences can be noted and handled. The debootstrap of the chroot will be almost the same as a freshly installed system. It didn't use the debian-installer and so there will be some differences. But I expect that list to be much shorter than the 2300 found on my system in the above check. Bob
Attachment:
signature.asc
Description: Digital signature