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
Attachment:
signature.asc
Description: Digital signature