[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
In message <[EMAIL PROTECTED]> on Fri, 03 Aug 2007 22:23:05 +0200, Ludovic Brenta <[EMAIL PROTECTED]> said: ludovic> I think the origin of the problem is that the files generated ludovic> by autoreconf are in the release tarball, That's normal behavior according to GNU standards, which we follow to a point. ludovic> but not in the working copy after a fresh checkout. That, too, is normal. A fresh checkout isn't the same thing as a distribution, and quite honestly, I would STRONGLY ADVICE anyone not to engage in the game of committing configure.in, configure, config.guess or any other of the automagically generated or copied files into any branch. The result is usually that as soon as a few people run different versions of the auto* tools, we get a version battle of sorts that are 1) difficult to review and 2) a huge distraction from what we should really review. ludovic> How about keeping these files in the .debian-diff branch? ludovic> That makes it possible to patch them if necessary, too. And ludovic> without rerunning autoreconf from debian/rules. That makes it a pain in the nether region to patch. There is one package that I can't build any more, simply because it contains a patch of configure which doesn't work because I've branched off a little, and did the mistake of using a DIFFERENT version of the auto* tools than the original author, which means that my branch contains a different configure and other files that said patch can't be applied on. The result is that dpkg-buildpackage barfs. I've yet to resolve the situation, but had I not been stupid enough to commit the automagically generated changes in those files in my branch, I wouldn't have had a problem. Do not follow my bad example. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
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
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
On 8/3/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: > "Zack Weinberg" <[EMAIL PROTECTED]> 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
"Zack Weinberg" <[EMAIL PROTECTED]> 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.) > > Alles klar? > zw 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 would propose an alternative: * 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). This makes it possible to build a Debian package like so: - unpack the release tarball - rename the top-level directory to monotone_VERSION.orig - cp --archive monotone_VERSION.orig monotone_VERSION - cd monotone_VERSION - checkout --branch org.debian.monotone . - dpkg-buildpackage -i'_MTN|\.mt'(note: this is in my .bashrc aliases :)) I think this is much more reproducible than your proposed policy, and more obviously correct (as opposed to just "correct"). * Remove the debian/ subdirectory from n.v.m, and thereby from the release tarballs. This removes the need for merges between branches, and most of the associated 'don't' rules and opportunities for error in your proposed policy, and consequently the need to enforce these rules. It also makes the release tarballs more distribution-agnostic. Thoughts? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
