Re: How to cope with patches sanely
Raphael Hertzog <hertzog@debian.org> writes:
> 1/ it seems that we agree that patches should be applied by default
> during unpack of the source archive. This means that dpkg-source might
> want to know which patches are currently applied (or we could get
> strange results while building the package with patches unapplied)... do
> we use the same format than quilt for that (.pc directory AFAIK)?
It would be ideal for quilt users, but I don't think it's necessary.
We're going to need to script the conversion from a quilt-managed tree to
a Debian source package and vice versa anyway, so I wouldn't put a lot of
effort into making dpkg-source produce a quilt tree.
I wouldn't worry about any metadata at all; dpkg-source would just apply
all the patches in the series file (or, really, we could just script a
conversion from quilt to wig&pen by appending arbitrary numbers to the
patches based on the series file and omitting patches not listed in
series).
If someone wants to work on the tree with quilt, then rather than using
dpkg-source -x they should use dpkg-quilt-unpack or some similar script
yet to be written that would create a series file, stick the patches in
debian/patches or some other likely location, and untar only the virgin
tarball.
> 2/ What should happen in Lars' scenario ? I suggest that dpkg compares
> the tree with the theoretical tree (orig+patches) and creates one patch
> more that it adds at the end of the patch serie. It would be auto-named
> "debian-upload-<version>" (so that it can be auto-replaced if the same
> package is built several times in a row during tests for example). (We
> could maybe even have some mechanism so that NMU uploads do not change
> the <src>-debian_<version>.tar.gz but instead push the changes affecting
> the debian directory in that auto-generated patch too)
That sounds perfect.
> This shouldn't be too difficult to implement. The interesting part is
> also providing support to generate that patch series using a VCS.
I can conceptually see how to do it with git given a set of feature
branches and an ordering, so it should be possible to work through.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: