Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy

[Zack Weinberg]

On 8/3/07, Ludovic Brenta <address@hidden> wrote:
> "Zack Weinberg" <address@hidden> writes:
> > * To make a Debian release, starting from a release tarball:  Rename
> > the release tarball to Debian's convention
> > (monotone_VERSION.orig.tar.gz).  Unpack it.  Take the diff between the
> > corresponding release tag and the head of n.v.m.debian-diff, and apply
> > it to the unpacked directory.  Proceed with dpkg-buildpackage.
> >
> > (You do not simply check out the head of n.v.m.debian-diff and run
> > autoreconf -i, because that risks skew between the generated files in
> > the tarball and the generated files on the branch, which will lead to
> > problems.)
>
> I kind of disagree with this proposed policy.  I find it too
> complicated and leaves too much opportunity for mistakes.  In
> particular, the part about applying a diff outside of a checkout
> worries me quite a lot, as it means the Monotone database does not
> directly contain the Debian scripts that are released.  I believe the
> whole point of maitaining packaging scripts in a version control
> system is to be able to make packages from within a working copy :)

I think I didn't explain things clearly enough.  The Monotone database
does directly contain the released scripts, and you could in principle
make packages from a checkout of nvm.debian-diff by running autoreconf
-i and then dpkg-buildpackage, as long as the current release tarball
was sitting in the parent directory.  The reason I don't recommend
this procedure is simply that it risks autoconf / automake version
skew (at best producing unnecessary junk in the .diff.gz, at worst
causing build failures).  Taking the diff between mainline and
.debian-diff and applying it to a non-working-copy unpack of the
release tarball avoids this problem.

> * Create a new independent branch named org.debian.monotone,
>   containing *only* the packaging scripts (i.e. the debian and, if
>   necessary, patches directories). (The new branch name is for
>   consistency with all the other packages I maintain with monotone,
>   but not mandatory; I would replicate this branch to my monotone
>   server on www.ada-france.org).

My problem with this suggestion is that we currently have to make
small changes outside the debian directory (see present content of the
branch).  I would really rather not drag in a build-time patching
system for them, especially as IMO storing Debian-specific changes as
proper changes to the files in a branch will be more convenient.  For
instance, if we backport fixes from mainline (which we did do for the
0.35 packages) they'll automatically get superseded by the next
upstream release when we merge from trunk to branch.

I see the question of whether there should be a debian/ directory in
trunk as entirely independent of how the branch holding
Debian-specific changes is managed.  I like having it on trunk, myself
- for instance, it means that schema upgrades can be checked in
together with the necessary update to monotone-server.postinst and
dummy entry in the Debian changelog.  (Although, having just typed
that, perhaps we should look for a way to eliminate the need...)

zw