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

Re: How to cope with patches sanely (Was: State of the project - input needed)



On Fri, Jan 25, 2008 at 06:00:02PM +0000, Raphael Hertzog wrote:
> On Fri, 25 Jan 2008, Michael Banck wrote:
> > On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
> > > On 25/01/08 at 08:01 +0000, Steve Langasek wrote:
> > > > As a second runner up, quilt is ok by me. :)
> > >  
> > > I made some stats (see [1]). 7.8% of our packages use quilt, while 14..4%
> > > use dpatch. It would be great to document in some place (devref?) why
> > > quilt should be used instead of dpatch, because I don't think it's
> > > obvious for everybody :)
> > 
> > And there I thought we'd use whatever we like until wig&pen lands, which
> > will have native patch support.
> > 
> > What's the status of that?  Is my assumption bad?
> 
> Not completely, I'm following the discussion closely as I really want to
> provide the required features in dpkg-dev directly. But I'm afraid that
> wig&pen as defined might not be enough for all cases.
> 
> And Joey already made a proposal for a 3.0 source package (wig&pen is 2.0)
> based on git. 

  I'm not sure we aren't mixing two different issues. There is the
exchange format used for source packages, and there is the question of
where DDs put all their work to generate those source packages.

  I'm less and less sure that a git-based format is a brilliant idea. I
like git more than a lot, but it's a poor idea to base source packages
on them. That doesn't mean that we shouldn't be able one day to upload a
signed git source url + sha1 signed with GPG and see DAK and other tools
git pull from there to rebuild the source package using some normalized
ways, but a source package should remain as simple as possible, using
_textual_ interfaces.

  IOW, all that you should need to grok what is in a source package
should basically be tar/ar/cpio/... and vi.


  Another thing is that people have the old habit to see the source
package be the preferred form of modification for a Debian package. I
mean, many DD do not save their packages in a SCM and use the archive
(and snapshots.d.net) as a SCM. Well, maybe that's the issue. Source
packages are just snapshots of the state of a Debian package, like
upstreams tarballs are the snapshots of the development of some
software. Usually upstreams prefer patches against the tip of their
devel branch rather than against their last released tarball. The same
is true for Debian packages.

  So maybe what we should do isn't trying to make the Debian source
package a complex mix between a snapshot and a SCM, but rather let it be
simple, and only a snapshot, and have ways to encode in it where to find
(and how to use to some extent) the SCM that was used to generate it.


  And in taht sense, wig&pen that allow you to put multiple diffs rather
than a single .diff.gz with your orig tarball is quite enough.
debian/control is already here for the rest, and we just need some more
Vcs-* like headers, or some new resource to list the proper Debian
packages upstreams (maybe in mole ?) since Vcs-* headers in a given
package cannot be updated if the maintainer changes, and that the Vcs he
uses changes location.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpyUUs8tFxxX.pgp
Description: PGP signature


Reply to: