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

["Bernhard R. Link" <brlink@debian.org>]

* Jasmine Hassan <jasmine.aura@gmail.com> [121010 04:45]:
> 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.

I think the solution is simple: either do your own .orig.tar or
do not rename files. Either you are doing a full fork and everything
on your own, then creating your own release tarballs is more logical
anyway. Or you want to do some minimal changes via patches,
then renaming files does not really make much sense anyway.

> 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.

With "3.0 (quilt)" there usually is no unpatching (except if you use
some explicit options). So if you need to revert the names, that would
be done in the clean target instead. But I really do not see the point
of renaming files if you want to stick close to the original.

        Bernhard R. Link