[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Package debian/ version control



While pulling source packages for an upcoming Finnix release, I noticed
many core Debian packages seem to be using Launchpad and bzr for
maintaining Debian packaging.  For example:

> $ apt-get source binutils
> NOTICE: 'binutils' packaging is maintained in the 'Bzr' version
control system at:
> http://bazaar.launchpad.net/~doko/binutils/pkg-2.22-debian
> Please use:
> bzr branch http://bazaar.launchpad.net/~doko/binutils/pkg-2.22-debian
> to retrieve the latest (possibly unreleased) updates to the package.

In this case, other branches are tracked at
https://code.launchpad.net/binutils .  I had been wanting to keep Finnix
packages in source control for some time, and this seemed like a sane
way of doing it.  Tonight I went through and prepared all Finnix
packages here:

https://code.launchpad.net/finnix

The way Launchpad organizes branches is a little counter-intuitive at
first, so here's what you're seeing: for
"lp:~fo0bar/finnix/finnix-keyring-pkg-debian", ~fo0bar is me, "finnix"
is the project, and "finnix-keyring-pkg-debian" is the branch.  Members
of a project can create and push branches for a project, within their
namespace, and everything is grouped by project.  Note that LP does have
a concept of distributions, but they seem to be handled specially and
are limited to a few specific distributions (Ubuntu, Debian, etc), so in
this case "finnix" is a project, not a distribution.

The packages can be broken up into three categories:

1. finnix-* native packages where I've put everything under debian/
(literally, the package root has nothing but a debian/ directory) so
everything is version controlled.
2. neale-* native udeb packages (NEALE is the base build system for
Finnix) where there is a bunch of source and binary junk in the package
root, so it's infeasable to version control everything.  In this case,
version control on debian/ is mostly for historical interest.
3. Other non-native packages, where you could theoretically grab the
upstream tarball, apply the bzr debian/ and build the package.

Keep in mind that if you do keep debian/ version controlled, whether it
be bzr, git, etc, be careful of the .bzr/.git/etc data leaking into the
source package when being built (lintian will complain about this).  I
use debuild to build the source packages, and giving -I and -i to it
will pass those flags to dpkg-source, which ignores most common VCS
patterns when assembling the source package.

Anyway, I just wanted to document what I've done, in case it's useful to
other derivative maintainers.  Note that I am also a Canonical employee,
so take my Launchpad endorsement with a small grain of salt. :)

RF

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: