Tue, 15 Apr 2008
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.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2008/04/15 09:05 | /operatingsystems/linux/debian | Permanent link to this entry | This entry + same date
Copyright © 2000-2005 Dean Wilson
