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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1333310474.2408.36.ca...@corn.betterworld.us
