Le Tue, Dec 29, 2009 at 10:33:45AM -0800, Russ Allbery a écrit : > > * Support for other compression methods. > * Multiple upstream source tarballs. > * Apply patches so that dpkg-source -x gives buildable source. > * Ship debian/* as a tarball instead of a patch. > * Allow binaries in the debian directory. > * Allow modified binaries in the upstream source. > * Standardize a patch format so that NMUers don't need to know so many. > The 3.0 source format does solve all of those problems. I think it may be > fair to argue that it suffers from some degree of second-system syndrome, > but that's an inherent risk in this sort of work.
In my opinion, much of the current disagreements come from two false needs: * Apply patches so that dpkg-source -x gives buildable source. * Standardize a patch format so that NMUers don't need to know so many. I remember the discussion that took place during DEP1 preparation. It already had the outcome that the main patch systems converged on a common interface: - Store the patches in debian/patches; - Apply them with ‘debian/rules patch’; - Document specificities in debian/README.source. There were some concerns that applying patches through debian/rules could be a security hole. In my opinion – that I already expressed in the DEP1 discussion – given that 1) dpkg-source will not extract packages that are not GPG-trusted, 2) the contents of debian/rules are easy to inspect and 3) in the case of NMU debian/rules is trusted, there was no necessity to ignore the de-facto standard interface: debian/rules patch. Personnaly, I am completely unconvinced of the necessity of applying patches at unpack time, nor of standardising on one particular patch implementation instead of using a clear patch interface as the one above (parts of which being already in the Debian Policy). If I am not the only one having this concern, maybe we could ask the technical comittee to give us its conclusions on this matter. I am ready to follow it. In parallel, having dpkg-source call ‘debian/rules patch’ if it exists would solve part of the conflict for the control of patching process. And this way we will not be blocked with quilt if a better system emerges later. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
