Bonno Bloksma wrote:
> While preparing for the upgrade from Squeeze to Wheezy I ran:
> -----<quote>----------
> linbobo:~# aptitude search "~c"
> c libbind9-50 - BIND9 Shared Library used by BIND
> c libdns55 - DNS Shared Library used by BIND
> c libdns58 - DNS Shared Library used by BIND
> c libept0 - High-level library for managing Debian package information
> c libisc50 - ISC Shared Library used by BIND
> c libisc52 - ISC Shared Library used by BIND
> c libisccc50 - Command Channel Library used by BIND
> c libisccfg50 - Config File Handling Library used by BIND
> c liblwres50 - Lightweight Resolver Library used by BIND
> c libxcb-xlib0 - X C Binding, Xlib/XCB interface library
> linbobo:~#
> -----<end quote>----------
You don't need any of those. You can purge them. Those are libraries
used by previous versions of packages, mostly bind9. The bind9
package is one of several that don't have a stable api and is rolled
forward to new versions when there are security issues.
> Now, how do I know whether I need those libpackages or not? After
> all I am supposed check whether these packages can indeed be safely
> removed.
I am not an aptitude person so... Being an apt-get person myself I
would use "apt-get autoremove --purge" to select those and remove
them. But that might include other things than your specific filter.
The only question for those packages are whether you have locally
modified one of the associated conffiles of them. If you haven't then
they are no problem to purge. If you have then purging will also
purge your local modification. Have you made any local modifications
to any of the associated conffiles?
> Am I supposed to run:
> linbobo:~# aptitude show bind9
> ...
> And look at the depends list?
No. I don't do that. I simply run 'apt-get autoremove --purge' after
every 'apt-get upgrade' and then examine what it wants to clean.
Because I always it it after an upgrade the list is always small and
only concerning immediately installed packages.
If it hasn't been done for a long time (I have seen 536 packages on
one machine that wasn't ever cleaned before) then I work through the
problem more carefully and it takes longer. Easier to keep up with it.
For me I note that lib packages in the rc state (removed but with
config files possibly remaining behind) are relatively safe. What
library packages have config files? (libpaper for one with a default
paper size.) But those are few and far between and rarely modified.
So 99.44% of the time they are safe to remove.
> But how do I know whether any other package needs those libs?
Your previous was ~c that I assume is the same as the rc state. Is
it?
dpkg -l | grep ^rc
If so then those have already been removed. Nothing else depends upon
them or those other things would also have been removed. The only
thing remaining behind is possible conffiles. I say possible because
the package may have been removed but not have any conffiles and still
be in the rc state.
> Looking just at libbindx-xx... I also have
> -----<quote>----------
> linbobo:~# aptitude search libbind*
> ...
> Should I run aptitude why against each package?
I will leave the rest of the aptitude questions to someone who uses
aptitude since I don't use it myself and don't know the quirks of it.
> This is the first time I have this many packages that might be
> obsolete on my system. What is the harm in just leaving them there
> before the upgrade?
There are two very important cases where those files must be cleaned.
One is that older packages in /etc/init.d/* did not previously contain
LSB headers. Debian has moved to a new init.d strategy and now
requires LSB headers for every init.d script. Those are used by
'insserv' to create the numbered symlinks in /etc/rc?.d/S*. But older
init.d scripts did not have LSB headers. The packages owning those
files have been removed and therefore the conffiles that remain behind
won't have them and because the package is removed neither will it be
upgraded to newer formats of those files. This will cause transition
to the new boot system using 'insserv' to fail.
In theory this should have been caught up during the Squeeze 6
upgrade. But I just helped a buddy with a dozen systems and he had
never made that cleanup and was stuck in the legacy boot mode from the
last major upgrade. This upgrade to Wheezy 7 left him with some
broken systems. So even though the cleanup and migration should have
already been done I have personally seen it not done.
The second case that routinely hits people with PHP web servers is
that they have at some point installed the old php5-gd package. Then
they removed it. But that leaves the old conffile behind. The
conffile never gets upgraded because it is removed. After upgrading
everything else the conffile produces errors trying to load a
nonexistent gd.so file. That conffile bug has been fixed in newer
packages (it is now in /usr/share instead of /etc now) but remember
that the packge has been removed and won't be upgraded anymore. That
dead conffile with the bug will remain behind until it is purged.
Again, that problem has been fixed in newer version of the package but
it is impossible to fix in the already distributed older versions.
Similar variations on the above types of cases.
> On the other hand I do like a clean system. ;-) Also I have more
> systems I need to upgrade, I would rather like to understand what to
> do and why.
This really needs a longer explanation than I can give at this
writing. Sorry. But for a quick check these commands will look for
the most egregious issues. Whether it is a problem or not depends
upon your particular system. But should be looked at.
List packages in the "rc" state like "dpkg -l | grep ^rc". Maybe
these should be purged. Use judgement. Have you modified any of the
/etc files locally and you want to keep the configuration?
grep-status -sPackage -n -FStatus "deinstall ok config-files"
List packages with no upstream associated with them. May not be a
problem at all. Must use judgement. I have packages installed that
have no live upstream that I want to keep using.
apt-show-versions | awk '/No available version in archive/{print$1}'
List packages that contain obsolete /etc/init.d conffiles. These
really, really should be cleaned. These are very likely problems.
dpkg-query -W -f='${Conffiles}\n' | awk '$NF=="obsolete"{print$1}' | grep ^/etc/init.d
List any package with obsolete conffiles. These may or may not be
real problems. Lint certainly. Good to clean so that you don't get
bothered by then in a future upgrade. Use judgement.
dpkg-query -W -f='${Conffiles}\n' | awk '$NF=="obsolete"{print$1}'
How does a live and fully upgraded package get obsolete conffiles?
Bugs! If a package doesn't remove the obsolete conffile correctly
then it is left behind as lint. The file existed in the previous
version of the package. The dpkg upgraded the package. The file is
still existing on disk. The new package does not contain that file in
the package list. Therefore dpkg marks the file as "obsolete". It is
a conffile and so the system cannot by policy modify the file for fear
of discarding a local admin modification. It is stuck until manual
intervention. If these bugs still exist they should be reported so
that the package can be fixed. Help reporting these bugs would be
appreciated to improve Debian. You are hitting them now. Other
people will too. But the improvement won't be seen until Jessie.
How do clean an obsolete conffile? If the package is installed after
removing the file then dpkg will realize this and remove the file from
the file list for that package.
1) Understand the situation.
2) Remove the file if that is the appropriate action.
3) Reinstall the package.
apt-get install --reinstall $PACKAGE
Hope that helps. I am sure it is incomplete in some way.
Bob
Attachment:
signature.asc
Description: Digital signature