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

Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage


On Tue, 29 Dec 2009, Stefano Zacchiroli wrote:
> On Tue, Dec 29, 2009 at 04:52:59PM +0000, Julien Cristau wrote:
> > > Format 3.0 is more than .bz2 support.
> > And we're saying .bz2 support is the only thing in it we care about, and
> > didn't need to come with 3.0's drawbacks.
> And I'm still saying that ranting _here_ about that is pointless.
> Submit a bug report (I've just looked for it, but I didn't find it, does
> it exist at all?), provide patches for it, and have them accepted by the
> dpkg maintainers and FTP masters. They day they'll refuse the patches or
> tag the bug as +wontfix you'll have a reason to complain and we will
> hopefully know the technical reasons why the involved maintainers thin
> it is a bad idea.

I would tag such a bug wontfix because I'm not interested in breaking
backwards compatibility. 1.0 is what it is, and I made the deliberate
choice to not change what it is and to fix all the known
problems/misfeatures in 3.0.

I welcome improvements to 3.0 so that it suits the needs of everybody but
I'm not interested in creating a 1.1 format that would be 1.0 with
bz2 support.

Actually I recently added the "--single-debian-patch" dpkg-source option
so that 3.0 can be used much like 1.0 for the case where people use a VCS
to store the debian changes directly on top of the upstream source code
(without using a patch system).

Most complaints seen are wrong-headed because you can do everything
you did in 1.0 with the new format if you really wish (although I largely
prefer that people use the quilt patch system if they were using a patch
system already).

I know of only one use-case that the new format does not support very
nicely and it's when you store changes both in the .diff.gz and in
debian/patches/ (with quilt). Currently the changes in .diff are applied
before the changes in debian/patches/ and with the new format the content
of the diff is moved in the "debian-changes" quilt patch at the end of the
series. Julien is doing that with xorg packages because he doesn't 
want quilt patches for simple cherry-pick, he only uses quilt for patches
that are really debian-specific divergence while the other changes are
mixed in the .diff and disappear semi-automatically when he imports a new
upstream version that contains the changes that were already
cherry-picked. I think some helper tools to auto-remove patches
that are already part of the git history would nicely solve this problem
but someone has to write such tools and Julien simply doesn't have the
time (xorg is enough maintenance work).

Raphaël Hertzog

Reply to: