Search This Blog


Saturday, August 9, 2008

How to show apt log history

Users of Debian-based distributions (myself included) often brag about Debian's supposedly superior package management tool-set. This tool-set includes a choice of several excellent package managers such as dpkg, apt, synaptic, and aptitude. The various tools are all first class at what they are designed to do.

In my opinion, one major feature gap is a command-line interface for viewing the apt change log. After a recent routine Etch package upgrade, I discovered that the grub menu.lst file got corrupted. So, I wanted to check the recent apt activities to find out which packages were the possible suspects.

A google search revealed that viewing change history is not that simple. Aptitude writes change log info to /var/log/aptitude. Synaptic users can get the same info through its graphical user interface. But is there a standard change log file that the most common Debian package managers write to? The second question is whether there exists a command-line tool for accessing it.

It turns out that such a log exists, and it is /var/log/dpkg.log. This is a single log file that records all the apt activities, such as installs or upgrades, for the various package managers (dpkg, apt-get, synaptic, aptitude).

Regarding a command-line tool for accessing apt history, there used to be a package named apt-history for viewing apt-get activities. Its web site suggests that work in the project has been discontinued due to the fact that dpkg now does logging. It went on to recommend the use of a simple bash function (also named apt-history) to access the log file (/var/log/dpkg.log)

Below is the bash function from that web site.
function apt-history(){
case "$1" in
cat /var/log/dpkg.log | grep 'install '
cat /var/log/dpkg.log | grep $1
cat /var/log/dpkg.log | grep upgrade | \
grep "$2" -A10000000 | \
grep "$3" -B10000000 | \
awk '{print $4"="$5}'
cat /var/log/dpkg.log

I've tried it, and it works.

To set it up, insert the above code into /root/.bashrc.

To run apt-history, you need to become root (for example, sudo -i). Entering apt-history with no parameter will simply dump the change log file. To select what activities you want to see, you can enter one of install, upgrade, remove, rollback as a single parameter to apt-history.

$ sudo -i
# apt-history install
2008-08-01 21:37:00 install googlizer 0.3-3
2008-08-09 08:20:54 install agrep 4.17-3
2008-08-09 08:28:26 install abuse-frabs 2.10-7
2008-08-09 08:28:27 install abuse 1:0.7.0-5

StumbleUpon Toolbar


mavior said...

I would give a try also to

Anonymous said...

Beautiful. Thanks.

Anonymous said...

uuoc spotted !!!

Benjamin said...

I noticed that the dpkg logs are split up and compressed in Ubuntu. I updated your script to include functionality to decompress them and pull them back together. You can find the script on GitHub at

frodeseverin said...

Fabulous, Benjamin.

The power of Free Software! Someone publishing a solution that works for them, and someone else expanding and customizing it to their needs.


Richard Hamnett said...

Useless use of cat !

BullShark said...

This is one of the reasons I like yum/rpm. Both dpkg/apt and yum/rpm have their pros and cons. yum in Fedora can do

yum history list
yum history undo # (replace with a number that you got from using the first command with list)

I will be playing with this function. I had also created this alias ->

alias pkglog="grep '\ install\ ' /var/log/dpkg.log"

That might need to made into a function if logrotate starts using gzip or bzip and creating more files. Anyway, thanks for the bash function.

mahasiswa teladan said...

hi..Im college student, this article is very informative, thanks for sharing :)

Anonymous said...

I just used the Mate log file viewer (toward dpkg.log), and set a search filter to "install", and a color. Then checked it, and also selected show matches only.

Alex said...

I have updated the already derived version of the script(s) on to make them work again on Ubuntu 14.04 - the contents of the basic scrip itself was not impacted, only the outer level script that tries to fiddle out the versions for getting the right range and snippet from the package change log.