Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
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
Reply to:
- Follow-Ups:
- Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
- From: Jasmine Hassan <jasmine.aura@gmail.com>
- Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
- From: Raphael Hertzog <hertzog@debian.org>
- Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
- From: "Bernhard R. Link" <brlink@debian.org>