Advice on use of patch system while hacking
Short version:
What's the best way to work with a dpatch-based package developing code
that will likely take many smallish iterations to get right?
Longer version:
I am working on some extensions to noweb, a literate programming tool,
to improve its handling of python files (see bug 661635 for details).
The Debian package uses dpatch, and I have already created a first round
of patches. But I keep running into trouble when I make further
changes; usually very early in the build process (dpkg-buildpackage -b
-D -uc) it runs make clean and unpatching fails. I think I now
understand the cause and a solution, but the solution seems terribly
cumbersome and I'm hoping for advice about a better way to proceed.
The cause is that after I make further changes to patched files they
don't match the existing patches, and so unpatching fails. Standard
advice seems to be to start from clean originals, run dpatch-edit-patch,
make changes, exit back to dpatch-edit-patch, and then build the new
sources (probably after making another copy?).
This is an awefully cumbersome way to debug. Is there a better way?
My procedure so far, in contrast, has been to build the package with
dpkg-buildpackage -b -D -uc and then edit the source tree; this means
I've been editing files after the application of all patches and I have
lots of intermediate build products lying around.
My patches also edit debian/changelog; I think that is an error and I
should simply edit the changelog without making a patch for it, or for
anything under debian. Is the rule "no patches for changes under
debian/" correct?
At least for awhile my changes will likely be focussed in one python
file; I am considering simply editing it in place (where it's installed
in the system) as a way of getting it right. Would that be reasonable?
An additional wrinkle is that most of the source files are themselves
built. That is, there is an "original" source file xxx.nw, which is
itself in noweb. Untangling that will produce "derived" files, e.g.,
xxx.c, or in my case xxx.py. The upstream sources and the ones
distributed with the debian package include both the original (xxx.nw)
and derived (xxx.c) files to avoid a bootstrapping problem (since
untangling is done by the package itself); the Makefiles mostly work
with the derived files. The patches present now patch both original and
derived files in the same patch; for my changes I separated the patches
for original and derived files into separate patches. Maintaining that
distinction may complicate the workflow further.
I also have a transitional issue about how to capture the changes I've
made since the last patch, but I think I can manage that. I'm not
entirely sure how to remove all the build stuff (last time I ran diff
and manually edited out all the built files), but maybe dh_clean or
debian/rules clean will help.
Thanks.
Ross Boylan
Reply to: