"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