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. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
