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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
