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

Re: Packaging automation - separation of 'debian/' directory



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.

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.

The script can also be used with pbuilder, like this:
DEBUILD=pdebuild mkdeb

> > Bonus points for a method that *doesn't* involve getting the source
> > from version control as part of the package build process. A big part
> > of (my) testing is attempting a build of the package from the working
> > copy of the source, *before* committing the latest changes to version
> > control.
> 
> Yup, you can do this from inside your regular working directory, and only
> use the above method for building the final packages.

This script also doesn't need network access.  If the repository is cvs or
svn, it will remove their files from the package source before building (but
only in $TMPDIR, of course).

Thanks,
Bas

[1] http://pcbcn10.phys.rug.nl/svn/trunk/mkdeb/mkdeb

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: