Re: [Monotone-debian] Uploading 0.42 for squeeze, and structure of the debian branch

[Zack Weinberg]

On Mon, Feb 16, 2009 at 2:14 PM, Richard Levitte <address@hidden> wrote:
> zackw> Could you live with the use of quilt+debian/rules patch, or dbs
> zackw> simple-patchsys.mk, or (archive permitting) package format
> zackw> 3.0(quilt)
>
> Uhmmmm, I'm not really sure what you're saying there, but I assume
> that you're talking about producing debian/patches/ with a set of
> patches

Yes.  This seems to be the way Debian in general is going; for the
.diff.gz to modify files in the upstream tarball is increasingly
discouraged.

> and I've seen such patches break horrendously (because they
> contained patches for configure, which got generated by a different
> version of autoconf on my system, which...  bleah!) when I'm trying
> to build the package using such things as dpkg-buildpackage, while
> patches that are in package_version.diff.gz apply beautifully.

I'm not sure I understand the scenario - if the rules file is written
correctly, patches to autotools-generated files should be exactly as
troublesome with debian/patches as without (basically, one applies the
patches before doing anything else).

I've occasionally been tempted to not ship any generated files in the
tarball and rely on an invocation of autoreconf at build time, but
that's orthogonal and has its own problems...

> zackw>  - you have to remember to do the merge from mainline to .dd
> I haven't really seen that as a problem.  Guess I missed that one...

I had a whole bunch of grief in the 0.40-x series because I needed to
backport entire files to the branch, which trips over our lack of
support for file sutures.

> zackw>  - you may get spurious diffs due to autotools version skew
> Hmmm, I've missed that one too, as I've produced the original tar file
> and the package on the same machine.

It pretty much isn't a problem for the -1 upload, but again, was a
huge headache in later revs of 0.40-x.

> zackw>  - once .stripped lands you will have to jump through hoops to
> zackw>    get dpkg-buildpackage not to include all of the Attic files
> zackw>    in the .diff.gz (this is the big one)
>
> Why?  After all, if the Attic files go into nvm and then we propagate
> that to nvm.debian-diff, why would that generate a diff?

Because the Attic files *aren't in the tarball* (which is the Right
Thing; after all, they'd have been deleted if not for die-die-die).
Thus, you have to force dpkg-source to exclude them, which would be no
problem if -i excluded directories named Attic by default, but it
doesn't. So we have the following three-way dilemma:

 - leave the Attic files in the .diff.gz (the ftpmasters will kill us)
 - rename Attic to something that -i excludes by default
   (the least unpalatable name I found was ",,Attic")
 - use -i with a custom regexp (which then suppresses the default, so it has to
   be really long, and there's no way to record a desired -i regexp in
the source).

> zackw>  - the clone command you suggest takes about 20 minutes,
> zackw>    whereas a new org.debian.monotone branch containing new file
> zackw>    copies of the debian/ files only would be much faster
>
> If you're regularly doing this, I assume you'd keep the database
> around and just update it regularly instead of cloning every time!

I'm thinking of NMUers here; we want to make it super easy for them to
get at the version control information they need.  Twenty minutes and
they get fed up.  Yes, netsync should be faster, but we've had *that*
problem how long now?

zw