Sorry, the subject should've --obviously-- been "Patching, renaming, ..., renaming, unpatching"
On Wed, Oct 10, 2012 at 4:27 AM, Jasmine Hassan <jasmine.a...@gmail.com> wrote: > 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 debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahbmyczabud27cmfiy4bhydmg3kpbyy7ykpcq6moqatiqs0...@mail.gmail.com