Some .deb tips
For one of our clients, we use Ubuntu for most of the infrastructure and customer application environments. While the quality of most packages in Debian and Ubuntu is very, very high, we do occasionally come across a package that has minor issues. In this post, I’m going to try to document some of the more common workarounds – these are fixes for corner-cases where the packaging system is doing “almost the right thing”, but where we need to coerce it into doing something a little bit different.
Backing up installed packages when you need to test a new package version
dpkg-repack is one of the handiest things in the sysadmin’s arsenal, when dealing with an installed system that may be somewhat out of date. The most common usage is this: take an installed package, and use the binaries and metadata that are installed on the system to reconstruct what the installed package file (the original .deb) must have looked like.
So if I do:
I should wind up with a php5-common_versionnumber-$arch.deb in the current working directory.
What’s this good for? Well – if you have to upgrade a package to try out a new version – you can work safely. Even if the version you have installed is no longer in the debian reposito ries – or available anywhere in the distro’s pool-dirs – you can still back up what you’re currently using.
Dealing with package file conflicts that prevent package installs or package upgrades
It happens fairly frequently that two packages will “disagree” about which package “owns” a particular file. This metadata about files is a fairly important part of a working Debian system, as it lets the dpkg tools figure out what files to upgrade, delete, overwrite, etc, when you upgrade or install a new package. Essentially, one package owns the files and new package installations should not be able to casually overwrite filepaths that they do not own.
Usually, this is no big deal – it tends to happen when a package maintainer decides that a file belongs in one package rather than another, or when an older and a newer package (let’s say – libmysqlclient15 and libmysqlclient-dev) both “claim” a file. When this happens, one has two choices as an end user: either wait for the package’s maintainer to release a new point release of the package, and fix the bug, or force dpkg to do the right thing.
In the latter case, we might do this:
On our system (which we’d been upgrading piecewise from an older Ubuntu (Gutsy) to a newer one (Jaunty, for the benefit of a newer mysql…) ) this overwrites a bunch of header files that libmysqlclient15 had owned.
Odds are that this situation might work itself out with the next release of the package – this is one of those situations where people generally get irritated, and where bugs get filed. If you don’t file bugs on package upgrades, *please do so – you’re helping the maintainer catch a bug that an average user might not know how to resolve, and which increases the overall quality of the package. This is a big win for users, and for other system administrators!
These are only a couple of useful tips – there are many features to dpkg, and many different ways in which you can put the packaging system to work for you, or tame it if necessary. If you have suggestions along these same lines, let us know!
Comments are closed.
Brandorr Group LLC is a one-stop cloud computing solution provider, helping companies manage growth and ship new projects using cloud and scalability best practices.