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

[Ludovic Brenta]

Zack Weinberg writes:
> 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.

I understand why we don't want to run autoreconf as part of Debian
packaging, and I agree with this.  I think the origin of the problem
is that the files generated by autoreconf are in the release tarball,
but not in the working copy after a fresh checkout.  How about keeping
these files in the .debian-diff branch?  That makes it possible to
patch them if necessary, too.  And without rerunning autoreconf from
debian/rules.

>> * Create a new independent branch named org.debian.monotone,
>>   containing *only* the packaging scripts (i.e. the debian and, if
>>   necessary, patches directories). [...]
>
> 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.

OK, that makes sense.

> 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...)

OK, that's convenient because you happen to be a Monotone developer
and the Debian package maintainer at the same time :)

-- 
Ludovic Brenta.