[RFC] export filters

[James Westby]

I am currently writing a new bzr-builddeb feature that is designed for a
branch that contains a full source of a package and it's debian/ dir.
This might be used when someone is both upstream and package maintainer
(they might use two branches, but this is possible). The feature takes
this branch and creates a non-native package from it.

For those not familiar with packaging this basically means that you
create an .orig.tar.gz with the upstream code, and then a .diff.gz with
the debian specific changes. In practice this is done by creating the
.orig.tar.gz and then using dpkg-buildpackage in a dir that has the
unpacked tarball and any debian specific changes (including the contents
of debian/). So I have to get from

  package/
  package/debian/

to

  package.orig.tar.gz
  package/
  package/debian/

where the orig.tar.gz doesn't include debian.

I am currently doing this by exporting to a temporary dir, blowing away
debian/ and then creating the tarball from that, blowing away the temp
dir and then exporting again. This isn't too much work, but it would be
great to use bzr's ability to export straight to a tarball.

So my feature request is to be able to specify a filter to export() so
that files can be excluded from the export. I think an exclusion feature
is better, though it could be the other way, or both. I think there are
use cases for both.

I don't mind whether this is exposed at the UI as builddeb is a plugin.
It could always be exposed later. I do have a couple of other uses like
this, but they are all the same idea for now.

I am thinking of extending this feature to use a configurable filter of
what goes in the .orig.tar.gz (or rather what is left out). I was going
to have a space(?) separated list of pathspecs that would be blown away.
This seems fine as long as they are relative and don't contain "..".
However I am not convinced that will be useful, and it would be easy
enough to do as a hook when I get round to writing hook support.

I realise this is probably a niche feature, and can be easily solved by
other means, but if I bring it up people may see other uses in it.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256