Aptitude and package upgrades

This shortish post is an attempt to share some of the difficulties why something like config::model could be good as shared in the previous post .

Two confessions to be made. First is I have been quite a long GNU/Linux user and have been bitten by apt, apt-get and aptitude on various occasions in the past.While the tools have obviously become better in time, some lessons being learned the hard way and hence try to err on the side of caution.

The second is this post would not have been possible without the help of a certain Daniel Hartwig (who’s now one of the developers of the package manager called aptitude) for Debian who explained some of the things that I’m going to share in this post.

A regular update/upgrade scenario involves the following things :-

a. Update the package index using your preferred package manager
b.Then look for upgrades and upgrade them (hopefully all without any conflict resolution, mostly clean on stable).
c.Clean the archive of obsolete and unwanted stuff.

Now while a. is important, its also trivial (IF your networking is right and are able to touch and get the repos correctly) b. and c. are the most interesting in this aspect.

Now when you run b. Something like :-

#aptitude safe-upgrade

You get something nice like this :-

#aptitude safe-upgrade
The following packages will be upgraded:
baobab gnome-dictionary gnome-font-viewer gnome-screenshot gnome-search-tool gnome-system-log gnome-utils-common


Upgrading these packages are easy in the sense, you upgrade about then and can forget about it but sometimes you get something slightly different as well. An e.g. :-


#aptitude safe-upgrade
The following NEW packages would be installed:
libgmime-2.6-0{a}
The following packages would be REMOVED:
libgmime-2.4-2

some in-situ packages which are upgraded …..

10 upgraded, 1 newly installed, 1 to remove

Need to get 30 MB of archives.
After this operation, 5 MB disk space will be freed.
Do you want to continue [Y/n]?

I have taken out all the other packages because I didn’t want to share extraneous stuff, what is interesting are the fate of these two packages. Let’s see if there is any difference between the two of them.


$ aptitude search libgmime-2
i A libgmime-2.4-2 - MIME message parser and creator library - runtime
p   libgmime-2.6-0 - MIME message parser and creator library - runtime


I have taken out the other hits just as before as we want to focus our attention on these two so we look at both of them. Some quick things, the small (i) denotes that the package is installed, the big (A) says its automatically installed/pulled in by some other package (a dependancy). The (P) says that your package manager has no history of this package being installed in the system, the package is unknown to it.

The other thing we see, is that both of the packages have the same description but as seen above due to some reason/some conflict they cannot be installed side-by-side.So we just go ahead and do the inevitable. We do as instructed by the package manager.

Note: There are tools where you can understand the relationships as to why some combinations of software versions are needed or not but we would not delve into that right now.

At the end of it if we look again, the situation would be slightly reversed with the package states.


$ aptitude search libgmime-2
c   libgmime-2.4-2 - MIME message parser and creator library - runtime
i A libgmime-2.6-0 - MIME message parser and creator library - runtime


Now what the package states for libgmime-2.4-2 is that the package is removed but somethings are remaining while libgmime-2.6-0 is now installed perfectly.

Now many people would have absolutely no issues with x number of obsolete and unnecessary packages lying in the system but I do. While obsolete packages can reclaim space, packages which have their config places in places could do a source of trouble in the future (one does not know.). Also because we do not have this config::model yet in place, we cannot just purge these packages blindly as they may have important data within them which perhaps needs to copied/backed up before purging the old stale package. The aptitude manpage is also clear about it in no uncertain way.

--purge-unused
If Aptitude::Delete-Unused is set to “true” (its default),then in addition to removing each package that is no longer required by any installed package, aptitude will also purge them, removing their configuration files and perhaps other important data. For more information about which packages are considered to be “unused”, see the section “Managing Automatically Installed Packages” in the aptitude reference manual.THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING!


It is interesting what it is saying. It is saying that apart from configuration files there is possibility of other important data being in a package and unless an administrator is absolutely sure (s)he should not purge them and they are right in that sense.

Before we tackle this case, there is one thing you can do to look within your system to see if there are such packages lying around :-

aptitude search ?config-files

Any listing this produces tells you that these packages may or may not have important data but the package itself has been removed during one of the updates/upgrades in the previous cycle.

But as I said I tend to tread on the err of caution, I want to see if something is there within those packages.

There are two ways to see this :-

$ dpkg -L libgmime-2.4-2
Package `libgmime-2.4-2' does not contain any files (!)


Another one is :-

$ dpkg-query --showformat='${Conffiles}\n' --show libgmime-2.4-2

$

Both these commands tell me there is nothing left in the removed package but wait didn’t we learn yesterday that configuration files can be in more than one place so let’s go to /var/lib/dpkg/info and see if we can find something.

$ cd /var/lib/dpkg/info
/var/lib/dpkg/info$ ls libgmime-2.
libgmime-2.4-2.list libgmime-2.4-2.postrm libgmime-2.6-0.list libgmime-2.6-0.postinst libgmime-2.6-0.shlibs libgmime-2.6-0.md5sums libgmime-2.6-0.postrm libgmime-2.6-0.symbols


Now as can be seen there are two libgmime-2.4-2 files, one with the extension ending as .list and the other ending with .postrm .

Now just to make sure that there’s nothing there just do a cat :-

/var/lib/dpkg/info$ cat libgmime-2.4-2.list
/var/lib/dpkg/info$


As can be seen this is an empty file. I could have also done a file-size listing as well. Now let’s see the other file.

/var/lib/dpkg/info$ cat libgmime-2.4-2.postrm
#!/bin/sh
set -e
# Automatically added by dh_makeshlibs
if [ "$1" = "remove" ]; then
ldconfig
fi
# End automatically added section


now I don’t want to go into details of the script, but its a shell script and says something about what the linker needs to do when this package is purged. It is a standard file which is there with every package, nothing special. You can find about them here and here.

Now the thing is if its like the above, why not do it all the time, why not simply purge them (which will remove the configuration files) and I do not have to do anything else. But the thing is as said in the aptitude document not all removed packages have just configuration files, they might have some other data as well and unless you know for sure its useless then do not purge.

Here’s an example of such an example :-

$ aptitude search ?config-files
c kdebase-runtime-data - shared data files for the KDE base runtime module


Now in this example as I use some KDE apps, some of them used to require this kdebase-runtime-data program/package and does no longer. This package is replaced with kde-runtime-data if the other packages need them but here’s the interesting part. This package has some files.

$ dpkg -L kdebase-runtime-data
/etc
/etc/dbus-1
/etc/dbus-1/system.d
/etc/xdg
/etc/xdg/menus


So at first glance you cannot purge it. Once its known by seeing the kde-runtime-data that the above files and path are there you can purge it.

$ dpkg -L kde-runtime-data | grep system.d
/etc/dbus-1/system.d
/etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf
/usr/share/desktop-directories/kde-system.directory


$ dpkg -L kde-runtime-data | grep xdg
/etc/xdg
/etc/xdg/menus
/etc/xdg/menus/kde4-information.menu


Note: You can also see the conflicts between the old and new packages by just using your preferred package manager and asking it to give more info.

$ aptitude show kde-runtime-data
Package: kde-runtime-data
State: installed
Automatically installed: yes
Version: 4:4.7.4-2
Priority: optional
Section: kde
Maintainer: Debian Qt/KDE Maintainers
Uncompressed Size: 9,651 k
Depends: perl
Breaks: kcontrol, kdebase-bin-kde3, kdebase-kio-plugins, kdebase-runtime-data (< 4:4.7.2), kdebase-runtime-data-common,kdebase-workspace-bin (< 4:4.5.95), kdelibs5-data (< 4:4.5), plasma-netbook (< 4:4.5.95), plasma-widget-networkmanagement (< 0.1+git20110422.810bc16-1+)
Replaces: kcontrol, kdebase-bin-kde3, kdebase-kio-plugins, kdebase-runtime-data (< 4:4.7.2), kdebase-runtime-data-common, kdebase-workspace-bin (< 4:4.5.95), kdelibs5-data (< 4:4.5), plasma-netbook (< 4:4.5.95), plasma-widget-networkmanagement (< 0.1+git20110422.810bc16-1+)
Description: shared data files for the KDE base runtime module
This package contains the architecture-independent shared data files needed to run KDE applications.

This package is part of the KDE base runtime module.
Homepage: http://www.kde.org/

See the Breaks:: and Replaces:: lines to get an idea.

And btw here’s an interesting link about versioning in perl I got while riding the interwebs the other other day.