Re: How to cope with patches sanely
In this message I'm only speaking about the orig.tar.gz+diff.gz and
patches-as-separate-files approach and its possible standardization.
I'm not very familiar with VCS brances approach.
Most of these thoughts have already been given by different people in
this thread. I just collect (some of) them together to one message with
a real life example.
Raphael Hertzog kirjoitti:
> Some questions/problems:
>
> 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)?
Standardizing the patch format would be quite elegant. It would probably
be the safest way to apply debian/patches/ automatically. Such a
behaviour may not be suitable for all packages and maintainers, though.
I take the vim package as an example. I'm not speaking behalf of Vim
maintainers; these are just my personal thoughts.
The upstream of Vim provides source packages and a set of numbered
patches meant to be applied to the source tree. The Debian vim package
(orig.tar.gz+diff.gz) contains the following files and directories
(among many others):
# Upstream tarballs:
vim-7.1/upstream/tarballs/vim-7.1-extra.tar.gz
vim-7.1/upstream/tarballs/vim-7.1-lang.tar.gz
vim-7.1/upstream/tarballs/vim-7.1.tar.bz2
# Upstream patches:
vim-7.1/upstream/patches/7.1.???
# Vim maintainers' patches managed with quilt:
vim-7.1/patches/*.diff
Before the package is actually built, "debian/rules extract" first
extracts the upstream tarballs, then applies all the upstream patches
and finally applies Vim maintainers' quilt-managed patches. To me this
seems to be very good way to handle debianized vim package. Upstream
archives and patches are as the upstream provides them and the Debian
part is separate from them.
Now, if all the patches should be automatically applied
by "dpkg-source -x", packages like vim should move all the upstream
patches to debian/patches/ directory as well as distribute the upstream
tarballs in extracted form inside the orig.tar.gz. Now doubt this is
possible but I think Vim maintainers' way is quite elegant to this
package.
But, if there were not any "standard Debian patch format" (maybe only a
recommended way) but a standard interface for (un)applying patches,
then it would be possible to handle varying situations. Let's say
that "debian/rules patch" would be the standard way. Then the vim
package's "debian/rules" could provide the 'patch' target which
extracts all the three tarballs, applies the upstream and downstream
patches and hence provides the ready-to-edit source form.
I agree with others that "debian/rules patch" shouldn't be run
automatically. It is a security risk to execute code from inside the
package the moment it is extracted. So maybe patches shouldn't be
automatically applied. I think it's not necessary. If there were easy
and standard way of doing so (like "debian/rules patch"), then
non-maintainers' job is not too difficult.
It seems clear that with packages like vim it's not possible to just
edit the source code and run dpkg-buildpackage. It's very likely to
lead to conflicting patch files. (The current vim package in Sid
applies 241 upstream patches and 34 Debian patches.) A non-maintainer
who wishes to fix a bug in such a package should either need to learn
the patch system used by the maintainers or use some not-yet-defined
standard interface for adding modifications.
The standard interface for modifications could be provided by some
external tool or a target like "debian/rules patch-new". I guess the
basic procedure for such tool(s) is to 1) ensure that all the patches
are applied (e.g. run "debian/rules patch"), 2) take a snapshot from
the source tree, 3) allow free editing, 4) make a diff of changes and
add it to the end of the patch series. I think it would be an advantage
if this procedure could be repeated so that separate logical patches
could be added.
If the standard interface for applying patches and making additional
modifications is provided through "debian/rules" then I think the
needed makefile targets in most situations could be included from some
standard include file like /usr/share/quilt/quilt.make. Only in special
cases the maintainers would need to provide the targets themselves.
This is how it seems to me. (Not all my original ideas, though.)
Reply to: