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

[Ludovic Brenta]

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