Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)

[Jasmine Hassan <jasmine.aura@gmail.com>]

Sorry, the subject should've --obviously-- been "Patching, renaming,
..., renaming, unpatching"

On Wed, Oct 10, 2012 at 4:27 AM, Jasmine Hassan <jasmine.aura@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