Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
Le Mon, Dec 28, 2009 at 12:44:29PM -0500, Joey Hess a écrit :
>
> I would prefer not to see such packages in the archive using source
> format 3.0. We've been down that road with 1.0, and it was not pretty.
> Above all other goals, my goal with putting the framework of source 3.0
> in place was to allow the flexability that that mess never need to
> happen again. Please try to respect that; the benefits of getting this
> consistently right, are widespread, diffuse, but very real.
Dear all,
My vision of pacakaging is the one of somebody who started in 2006. At that
time, my impression was that there was a momentum for moving away the
management of the patching of the upstream sources from dpkg to the package
maintainer. In the context of the format 1.0, I found that move very welcome,
as it allows to break-up a monolithic change into more logical units. Also,
it seems to me that it fits well the ‘Unix philosophy’ of using a combination
of simple tools to perform a complex task.
Consistent with that trend, the three major patch systems used in Debian
unified their interface, in order to let developers apply and deapply patches
with ‘debian/rules (un)patch’ (see http://wiki.debian.org/debian/patches ), and
the Policy now documents this in § 4.9 (not for unpatching). In supplement to
this, README.source points at a more extensive documentation on how to
manage the patches with the different systems.
In parallel, team maintainance of packages in a VCS is also gaining popularity.
In this model, the preparation of an upload is not based on the Debian source
package, but on on the VCS trunk, that may already contain some modifications.
Said differently, the fist step is not ‘dpkg-source -x’, but ‘debcheckout’.
Moreover, some tools like svn-buildpackage offer the possibility to only store
the debian directory of the source package. This leads to a different model of
building where each attempt is made from a clean unpacked original tarball.
Somewhat similarly, the use of git allows to reset the repository very easily
to its original state. In both cases, it looks simpler to me if the patching of
the sources is not done by dpkg itself, but by ‘debian/rules patch’.
Among the remaining problems in 2006, there was the impossibility to ship a
binary file that is not in the original upstream source, the lack of support
for popular formats of upstream archives, such as tar.bz2 and .zip (and
therefore .xpi and .jar), and the impossibility to aggregate multiple upstream
sources in the same Debian source package without creating an artificial
orig.tar.gz.
The source format versions 3.0 (quilt) solves much of the issues in the above
paragraph, but comes with its own patch management system. How about introducing
a new 3.0 variant that has the following features:
- no patch management at unpack time (use debian/rules patch).
- no patch management at pack time (the debian dir is made
in a tar.gz archive, without looking at the upstream directories).
Would such a format have a chance to be accepted some day in our archive?
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: