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 <email@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.