Dear Mentors, I'm surprised this topic hasn't been covered, as I thought it would be important, at least in some cases.
For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at least initially, requires a lot of code substitutions, and quite a few file/dir renaming. (ex.: gnome -> mate, gconf -> mateconf, metacity -> marco, etc.) I use a home-brewed migration script to generate actions for that. Now, doing `quilt add files_to_rename new_filenames; mv files_to_rename new_filenames; quilt refresh`, alone, would make a huge, unnecessary patch. I might as well modify the upstream tarball and use that as the orig, which, of course, is not proper. But, if I could rename the files just after patching, and rename back just before unpatching, then I can keep a *much* smaller sized debian/patches/*, and also generally more portable. Unfortunately, use of override_dh_quilt_(un)patch isn't feasible as it would require doing dh $@ --with quilt, which is against '3.0 (quilt)' source package format policy. Trying to do both at the same time; "--with quilt" and "3.0 (quilt)" format, results in dpkg-source --after-build breaking the build process, because the override_dh_quilt_unpatch is never invoked at that stage. Going back to source format 1.0 isn't a desirable option. So, I was doing something like: -- dh $@ --with autoreconf override_dh_auto_configure: [ -f new.c ] || mv orig.c new.c ... dh_auto_configure -- $(confflags) override_dh_clean: [ -f orig.c ] || mv new.c orig.c .. dh_clean -- But, unfortunately, that also breaks when dpkg-source --after-build is invoked, because it skips the rules file, and of so override_dh_clean has no effect to it. Same sad story was covered on this list *months* ago, with no proper solution: http://lists.debian.org/debian-mentors/2012/05/msg00131.html It basically ends with: It's a bug, just use "debuild -tc". This basically just tells dpkg-buildpackage to run `fakeroot debian/rules clean`, before it calls `dpkg-source --after-build`. But has this even been reported as a bug, yet? Shouldn't it be? Meanwhile, I thought I could find a straightforward workaround, in debian/rules itself, as I noticed dh_gencontrol happens right before dpkg-source is invoked, and since I already had an override_dh_gencontrol, I tried to separate my reverse-renaming into a seperate sequence, to be called from both override_dh_clean and the former. Like so: -- pre_unpatch: [ -f orig.c ] || mv new.c orig.c ... override_dh_clean: pre_unpatch dh_clean override_dh_gencontrol: pre_unpatch dh_gencontrol -- $(gencontrol_V_opts) -- But that didn't make the slightest difference. Nor did calling dh_clean (which is overridden to reverse-rename files) from override_dh_gencontrol. Nor with override_dh_builddeb. Nothing of all the aforementioned would allow the reverse-renaming in the debuild process before dpkg-source was invoked. Finally, I found something that works: override_dh_builddeb: pre_unpatch dh_builddeb Shouldn't this be mentioned anywhere? At least in 3.0 (quilt) docs? Is renaming files after patching and before unpatching advised against? Is there a better solution? Best, Jasmine -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAHbMyCaYNYS=moudvvrxzr9m2zk5m9q-d-hxn9mnnvr8v2f...@mail.gmail.com
