[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: