Re: Packaging automation - separation of 'debian/' directory
On Thursday 07 September 2006 08:14, Bas Wijnen wrote:
> On Wed, Sep 06, 2006 at 09:48:42PM -0700, Russ Allbery wrote:
> > Ben Finney <ben@benfinney.id.au> writes:
> > > I've seen many recommendations that the 'debian/' directory should not
> > > be part of the 'foo_X.Y.orig.tar.gz' tarball but should always be added
> > > by the 'foo_X.Y-Z.diff.gz', even in the case of "I *am* the upstream
> > > and I prefer to track the 'debian/' directory as part of the source
> > > tree in my VCS".
> > >
> > > So that leads to the question: What "best practices" are there for
> > > creating the Debian sources ('foo_X.Y.orig.tar.gz', 'foo_X.Y-Z.dsc',
> > > 'foo_X.Y-Z.diff.gz') automatically from a source working tree that
> > > already contains the 'debian/' directory?
> >
> > I just exclude the debian/ directory from make dist so it isn't included
> > in the official distributions. Then, to build the final Debian package,
> > I take the last official distribution, rename the tarball to
> > .orig.tar.gz, untar it, and then export the latest copy of the debian/
> > directory from my revision control system into the newly created build
> > tree.
>
> That's what I do for releases as well. For normal testing builds though
> (that's to see if the package builds and works without planning a release),
> creating a tarball and unpacking it first is too much work IMO. So I wrote
> a script to do these things for me. In fact, it does everything in
> $TMPDIR, so the working directory is completely untouched. You can find
> the script here[1]. There's also an attempt to auto-create a
> ${packagename}-dbg package including debugging symbols, but it's a bit
> fragile.
You might want to have a look at similar 'sourcetar' script to create upstream
and debian-style tarballs:
http://svn.sourceforge.net/viewvc/stealth/trunk/
Then you can use your favorite <VCS>-buildpackage.
(in that case in fact debian/ dir is managed in a separate repo, for
fine-grained separation ;-)
> Also, someone noted that this script is vulnerable to a symlink attack in
> /tmp. I haven't found a good solution for that though, because I want to
> have a reachable build tree under a "normal" name, where I can see what all
> the files look like.
Why do you need to bother with /tmp anyway ?
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: