Raphael Hertzog <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
