Pavel Volkov wrote: > Bob Proulx wrote: > > In the future if Debian changes to a new init then it will be set up > > such that there is an upgrade path from one to the other. Because > > there are *lots* of Debian machines out in the world and Debian is all > > about being able to upgrade. > > It's great to hear that, I never upgraded Debian the official way (only > reinstalled, for a few reasons).
In my opinion one of the best features of Debian is that it supports upgrades. It isn't necessary to reinstall. At worst it is easier to take some _packages_ (some packages not the system, such as GNOME or KDE) off the system before doing a full upgrade and then re-installing those packages. But that is so much easier than dealing with the entire system. > Kind of related question : is there a tool for removing all config > files that aren't used by any currently installed package? Yes. By not used I assume you mean from a package that has been installed and then been "removed". Removed is different from "purged". A package that is "purged" has all related files removed including conffiles in /etc. A "removed" package has conffiles in /etc left behind so that the package could be installed again and the previous configuration resumed. That is very convenient. But it means that a lot of systems build up a lot of old files in /etc from packages that have been removed. Sometimes those old files cause problems. Get a list of removed packages that still have conffiles remaining behind. $ dpkg -l | grep ^rc Then remove the packages that you don't want. I will mention some tools for helping with this process but it can't be fully automated because no one but you as the local admin know what files in /etc you have edited that you want to keep around. deborphan orphaner I tend to use grep-status to search for these. $ dpkg -l | awk '/^rc/{print$2}' Or using the more precise tools for the task: $ grep-status -sPackage -n -FStatus "deinstall ok config-files" Then after inspection I purge the list. dpkg --purge $(grep-status -sPackage -n -FStatus "deinstall ok config-files") Sometimes I hit all of the library packages first. Because I don't usually edit config files associated with libraries. Libs start with the ^lib pattern. That can quickly reduce the size of a large list from an unmaintained machine so that the interesting packages are more visible. grep-status -sPackage -n -FStatus "deinstall ok config-files" | grep ^lib What problems do these "rc" packages with conffiles left behind cause? Here are a couple of the most common reasons. The most notable source of problems are /etc/init.d/foo where foo doesn't have current LSB headers. Those files cause problems when upgrading because the new 'insserv' program used in Wheezy to set up parallel booting can't work without the dependency information in the LSB headers. Those files and packages should definitely be cleaned up. The second notable source that I see is in PHP libraries. Historically most often in the php5-gd package but also some others. Installed packages install the gd.so library. Removing it will remove the library but leave the conffile that loads the library behind causing a restart of Apache to complain that it can't load the library that it is configured to load. I think this is fixed in all current packages for a while but older packages that are "removed" but still with conffiles remaining behind do not get upgraded. So they are stuck in time with the old broken problem. Solution is to "purge" the package that owns the conffile and is causing trouble. Bob
signature.asc
Description: Digital signature