Re: How to cope with patches sanely
Raphael Hertzog <hertzog@debian.org> writes:
> This seems less than ideal to me. If we want to avoid proliferation of
> patch management system, I'd rather integrate some of those
> functionalities in dpkg-dev proper. IMO we need at least some building
> blocks (API?) so that VCS-based package management tools can easily
> integrate (new) patches in the Debian source package (or define the
> whole patch series for that matter).
Well, assuming that you're not anticipating people would use tools in
dpkg-dev instead of a patch management system, we're talking about
defining an export format that can be generated from a given patch
management system or VCS. Ideally, the results should be importable into
a patch management system (including a different one than the originator
started with). Importing into a VCS doesn't make a lot of sense beyond
the obvious (each patch as a separate commit); if you want to use the full
VCS, you really want to just clone the upstream repository.
So, we need a bijective translation that doesn't lose information, but I
don't see dpkg-dev filling the role of the patch management system
itself. In other words, I should be able to go to a quilt-managed tree of
source and patches to a Debian source package and back again, but I don't
expect to have tools in dpkg-dev that do the equivalent of quilt import or
quilt edit or quilt fold.
Either using a source format that consists of the original tarball, a set
of patches, and a series file, or a source format that consists of the
original tarball and a set of numbered patches should work for this. It's
pretty trivial to write a tool that converts to and from quilt format for
either of those layouts, and to work on that source without using quilt at
all.
The tricky part, as you mention, is what to do with modifications made
without a patch system on top of a source package that uses patches. I
think you've already described the obvious thing to do: take all the
additional modifications and turn them into another patch, placed at the
end of the patch series. The trick is finding the additional
modifications. If you have the original source package, you can always
use the brute force approach, but it probably would be better to stash
enough information so that one can reconstruct the original patched tree
and diff.
Note that the quilt format may not be a reasonable way of storing that
information. quilt essentially stores, for each applied patch, a backup
of every file affected by that patch before the patch was applied in the
.pc directory. That means that quilt doesn't have enough information to
build a patch out of new modifications unless you tell quilt which files
you're going to edit so that it can stash a backup file that it can diff
later. If you aren't going to tell some system which files you're editing
before you edit them, you need to either keep the original source tarball
plus patches around to rebuild the original tree or otherwise keep a copy
of the original unpacked tree in its entirety.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: