Creating Virtual Debian Packages - Debian Delving

Now that we have a local apt repository we can start to fill it with our own custom goodness. One of the first things I’m going to need is virtual packages. At work we’ll be using them to pull reusable components together in to a number of full applications (and using the apt mechanisms to force upgrades when a component changes) and to group Nagios plugins (we’ll be packaging some of those in a later blog post) in to sensible sections; we’re going to have a lot of Nagios plugins.

Unfortunately I can’t talk about those in detail on a public website that not enough people read, so we’ll need a more contrived example. Although I understand the reasons behind it (and appreciate them on servers) the fact that Debian doesn’t have a perl package that INCLUDES THE CORE PERLDOC bites me every now and again so we’ll make our own perl package that pulls in a handful of the existing packages.

Tangent - I think the three packages should be perl-base, perl-modules and perl-doc which anal people like me can pick for their systems. The perl package should be a virtual one that includes (and forces the install of) all three of those so you get a more intuitive setup for people that don’t need huge amounts of customisation. This could also be done with Ruby to hide some of the bat shit splitting of it’s libraries under Debian. But that’s all personal opinion; and now I’ve got virtual packages and an apt repo I can do what I want. Bwhahahaha.

While I was trying to work out how to do this I found the equivs package and it’s got one of the best descriptions I’ve ever read:

$ apt-cache show equivs | less
... snip ...
Description: Circumvent Debian package dependencies
 This package provides a tool to create Debian packages that only
 contain dependency information.
 .
 One use for this is to create a meta-package: a package whose sole
 purpose is to declare dependencies and conflicts on other packages so
 that these will be automatically installed, upgraded, or removed.
... snip ...

In additional to being a very clear statement of intent this is obviously the command for us. So how do we use it?

# on the build machine, which also hosts our sample repo.
$ apt-get install equivs

$ equivs-control perl-full

# edit the file to suit - example linked to from the next paragraph
vi perl-full

# build the meta package
equivs-build perl-full

# copy it in to our repo - which lives under 
cp perl-full_1.0_all.deb $repo_base/dists/pool/main/

# rebuild the index
pushd $repo_base && apt-ftparchive generate $repo_base/apt-ftparchive.conf

Here’s an inline version of the perl-full example control file that I used.

Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: perl-full
Version: 1.0
Maintainer: Dean Wilson <dean.wilson@example.com>
Depends: perl,perl-doc,libdbi-perl
Architecture: all
Description: Perl install that includes perl-doc and libdbi-perl packages.
 I'm fed up of installing perl and not getting perl-doc. This virtual
 package fixes that for my local systems and any other that can reach my
 apt repo
 .
 I don't recommend anyone else using this as it was written as an
 experiment and to voice how much having to install perl-doc bugs me.
 Oh, and this isn't a good example of a description. Look at real Debian
 packages for much better ones.

On the client you can do an apt-get update ; apt-get install -s perl-full and you should get a list of the packages that will be installed, which on a system that’s not already got a perl install should now include perl-doc.

While this example is a bit forced (and very opinionated) the technique and technology behind it are useful tools that are worth knowing.