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!
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.
220 Broadway (19th fl)
New York, NY 10038
We'd love to hear from you,
please feel free to call us:
With decades of experience in cloud technologies and specialties in high volume/throughput, high availability, and disaster mitigation engineering, Brandorr Group has the experience to help customers of all sizes develop, deploy and manage their new or existing infrastructure in the cloud.
By using provisioning and configuration management technologies such as Docker, Ansible, Chef, Puppet, Terraform, and CloudFormation, we are able to quickly and cost-effectively scale and deploy infrastructure projects of any size.
Additionally, Brandorr maintains 24x7 systems engineering, security and monitoring teams augmented by database administrators and software developers to ensure projects are delivered and systems remain highly available while maintaining performance.