Hacking the dependencies of a downloaded Debian package

The problem

When version 4.4.3 of KDE package kdebase-workspace went into testing, it brought with it a dependency on libkworkspace4 which conflicted with kdebase-workspace-libs4+5. You may remember that package from a previous blog post of mine where I created a fake kdebase-workspace-libs4+5 package which was needed to install the Karmic Koala version of plasma-widget-adjustableclock. As I wanted to keep up to date with the latest approved version of KDE, I installed the new kdebase-workspace and libkworkspace4 packages, resolving the conflict that they introduced by removing my fake kdebase-workspace-libs4+5 package and the Ubuntu plasma-widget-adjustableclock I had worked so hard to install.

While doing this, I assumed it would be just a simple matter to get the latest version of the clock package from Ubuntu and install that, at worst having to create a new fake package. I downloaded the latest Ubuntu version of that package, in Lucid Lynx, and sure enough when I went to install it I got this message:

Unpacking replacement plasma-widget-adjustableclock … dpkg: dependency problems prevent configuration of plasma-widget-adjustableclock: plasma-widget-adjustableclock depends on libkdecore5 (>= 4:4.3.4); however: Package libkdecore5 is not installed. plasma-widget-adjustableclock depends on libkdeui5 (>= 4:4.3.4); however: Package libkdeui5 is not installed. plasma-widget-adjustableclock depends on libplasmaclock4a (>= 4:4.4.3-1ubuntu1); however: Package libplasmaclock4a is not installed. plasma-widget-adjustableclock depends on libqt4-dbus (>= 4:4.7.0~beta1); however: Version of libqt4-dbus on system is 4:4.6.2-4. plasma-widget-adjustableclock depends on libqt4-svg (>= 4:4.7.0~beta1); however: Version of libqt4-svg on system is 4:4.6.2-4. plasma-widget-adjustableclock depends on libqtcore4 (>= 4:4.7.0~beta1); however: Version of libqtcore4 on system is 4:4.6.2-4. plasma-widget-adjustableclock depends on libqtgui4 (>= 4:4.7.0~beta1); however: Version of libqtgui4 on system is 4:4.6.2-4. dpkg: error processing plasma-widget-adjustableclock (—install): dependency problems - leaving unconfigured Errors were encountered while processing: plasma-widget-adjustableclock

The most notable part here being the libplasmaclock4a version required: 4.4.3-1ubuntu1. Unsurprisingly this package version could not be found in Debian, only version 4.4.3-1, so I knew this was going to be a problem.

The solution

As part of trying to solve this problem, one thing I did was talk to the Ubuntu packager of this software and ask him why there was a hard-coded dependency on Ubuntu. Of course, he is not paid to make packages work with Debian, and he especially isn’t paid to answer the questions of random Debian users online, but when I contacted him on IRC he was more helpful and approachable than any paid “customer services representative” I have had to deal with. Not that I am encouraging every newb on the planet to stalk the productive contributors to the Free Software community, but I do want to point out this practical benefit of the Open Source philosophy.

In the conversation I had with him, he was unable to remember off hand why the package had that specific dependency (and I was happy to give him the benefit of the doubt), but he did confirm that it was possible to just hack the package with a text editor to change the dependency string. I thanked him, and off I went to carry out this procedure, which I record below for future reference and for anyone who is tempted to try the same sort of hack.

The first step of course is to download the package and put it in a directory where you can work on it. I did something like:

mkdir plasma-widget-adjustableclock cd plasma-widget-adjustableclock wget http://…/plasma-widget-adjustableclock_2.2-0ubuntu4_amd64.deb

It is at this point that I should note that a .deb file is actually just an archive of other files. The precise archive format, however, is not one many people will have heard of. Debian avoided the ZIP format so common in the Windows world, and the almost ubiquitous tar and gzip from the Unix world, and instead went with the ar format. The reason? Because “every Unix system can be relied upon to have this standard tool.” So, one might think that all that is required is to run the /usr/bin/ar binary from the binutils package in Debian, and indeed you do, except binutils is Priority: optional, which means it doesn’t come on a Debian system by default, so not every Unix system can be relied upon to have this standard tool.

The tar and gzip packages, however, are Priority: required, which is useful, since when you do unarchive the .deb file you get two .tar.gz files which can be uncompressed with the standard, required tar and gzip programs! If that weren’t mind-numbingly stupid enough already, it gets worse. It turns out there are actually several contradictory standards for the ar format, and the tools in Debian support at least two different contradictory ones. Quoting from an 8 year old unclosed bug report: Well, uh, the HP man page describe an AR format that is different from that described by 4.4 BSD, and different from what original dpkg-deb supported.

That isn’t the end to the stupidity, though, and there is more frustration to come when actually trying to use the software in Debian, as explained a bit further below. Fortunately, however, the unarchiving process wasn’t so difficult, and only involved a few commands, like so:

ar -xv plasma-widget-adjustableclock_2.2-0ubuntu4_amd64.deb tar -xvzf control.tar.gz mped control

which loads the package’s dependency control file in the wonderful mped text editor. There you can change the line:

Depends: libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libkdecore5 (>= 4:4.3.4), libkdeui5 (>= 4:4.3.4), libplasma3 (>= 4:4.2.98), libplasmaclock4a (>= 4:4.4.3-1ubuntu1), libqt4-dbus (>= 4:4.7.0~beta1), libqt4-svg (>= 4:4.7.0~beta1), libqt4-webkit, libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.7.0~beta1), libstdc++6 (>= 4.1.1)

to:

Depends: libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libkdecore5 (>= 4:4.3.4), libkdeui5 (>= 4:4.3.4), libplasma3 (>= 4:4.2.98), libplasmaclock4a (>= 4:4.4.3-1), libqt4-dbus (>= 4:4.7.0~beta1), libqt4-svg (>= 4:4.7.0~beta1), libqt4-webkit, libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.7.0~beta1), libstdc++6 (>= 4.1.1)

and begin the more annoying process of reassembling your package.

The first step of creating the control.tar.gz file isn’t so hard, if you’ve used tar before, and the invocation to use:

tar -czf control.tar.gz md5sums control

is fairly easy to work out from the manual, but it is the invocation for ar which is the tricky one. Based on the invocation for tar, you might try:

ar -c package.deb debian-binary control.tar.gz data.tar.lzma

but seeing that doesn’t work, you might consult the manual which gives this synopsis ar [—plugin name] [-X32_64] [-]p[mod [relpos] [count]] archive [member…] and try:

ar -pc package.deb debian-binary control.tar.gz data.tar.lzma

Failing that, you could try:

ar -p c package.deb debian-binary control.tar.gz data.tar.lzma

and:

ar pc package.deb debian-binary control.tar.gz data.tar.lzma

all to no avail. You would then have to search through the manual until you find mention of the r parameter which, it says, is used to Insert the files member… into archive (with replacement). So, you would try:

ar prc package.deb debian-binary control.tar.gz data.tar.lzma

and, when that didn’t work, finally:

ar rc package.deb debian-binary control.tar.gz data.tar.lzma

I indeed tried all of those lines, proving to myself that the man page was pretty much useless and I should have just looked up the secret incantation on a blog somewhere, like this one. So, the last 3 commands I had to enter were:

ar rc plasma-widget-adjustableclock_2.2-0hagfish0_amd64.deb debian-binary control.tar.gz data.tar.lzma su dpkg -i plasma-widget-adjustableclock_2.2-0hagfish0_amd64.deb

using su to change to root because sudo is a poor tool.

Conclusion

Those, then, are the steps needed to take apart a Debian package you’ve downloaded, mess with its internals, reassemble it, and install it. Until you realise that libqtcore4 version 4:4.7.0~beta1 (or greater) isn’t in Debian testing, only Debian experimental, and as Debian is freezing testing ready for the next stable release, no experimental software is going to enter it any time soon. That leaves two options if you don’t want the excessively wide default digital clock widget in your KDE panel: don’t upgrade KDE, or go without a digital clock at all. I have actually gone without on one of my systems, opting instead for the less precise analogue clock, but is this what we have come to, KDE and Debian kicking us out of the digital age?