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

[Richard Levitte]

In message <address@hidden> on Mon, 16 Feb 2009 14:54:09 -0800, Zack Weinberg 
<address@hidden> said:

zackw> On Mon, Feb 16, 2009 at 2:14 PM, Richard Levitte <address@hidden> wrote:
zackw> > Uhmmmm, I'm not really sure what you're saying there, but I assume
zackw> > that you're talking about producing debian/patches/ with a set of
zackw> > patches
zackw> 
zackw> Yes.  This seems to be the way Debian in general is going; for the
zackw> .diff.gz to modify files in the upstream tarball is increasingly
zackw> discouraged.

Ok...

zackw> > and I've seen such patches break horrendously (because they
zackw> > contained patches for configure, which got generated by a
zackw> > different version of autoconf on my system, which...  bleah!)
zackw> > when I'm trying to build the package using such things as
zackw> > dpkg-buildpackage, while patches that are in
zackw> > package_version.diff.gz apply beautifully.
zackw> 
zackw> I'm not sure I understand the scenario - if the rules file is
zackw> written correctly, patches to autotools-generated files should
zackw> be exactly as troublesome with debian/patches as without
zackw> (basically, one applies the patches before doing anything
zackw> else).

Hmmm, in said package (damn if I remember which one it was, all I
remember is hell), it seemed that the patching from debian/patches
were applied after a round of autoconf...  The patches from
package_version.diff.gz are always applied when unpacking the source,
i.e. are directly applied on the contents from the original tarball,
which seems like the consistent thing to do.

But hey, if the current recommendation can hold a similar consistency,
I think I can work with it.

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

And it's contrary to GNU guidelines.

zackw> > zackw>  - you have to remember to do the merge from mainline to .dd
zackw> > I haven't really seen that as a problem.  Guess I missed that one...
zackw> 
zackw> I had a whole bunch of grief in the 0.40-x series because I
zackw> needed to backport entire files to the branch, which trips over
zackw> our lack of support for file sutures.

Ok.

zackw> > zackw>  - you may get spurious diffs due to autotools version skew
zackw> > Hmmm, I've missed that one too, as I've produced the original
zackw> > tar file and the package on the same machine.
zackw> 
zackw> It pretty much isn't a problem for the -1 upload, but again,
zackw> was a huge headache in later revs of 0.40-x.

Ok.

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

D'uh on me ;-)

At this point, you got me convinced...  :-)

Thanks for wanting to talk about it.

Cheers,
Richard

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish