[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
# Upstream patches:
# Vim maintainers' patches managed with quilt:

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 

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: