Re: How to handle Debian patches
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
> On Sat, 17 May 2008, Joey Hess wrote:
> > Raphael Hertzog wrote:
> > > On Fri, 16 May 2008, Joey Hess wrote:
> > > > Coming up with a complex set of requirements that everyone has to follow
> > > > up front in their workflow is not going to yeld the best results, and
> > > > I think that's my core reason for disliking Raphael's proposal. Now, if
> > > > you can come up with protocols/interfaces that can be used to
> > > > publish/communicate patches, that are managed/generated in whatever way
> > > > is most useful for the maintainer, that seems more likely to work.
> > >
> > > Aren't "patch files in debian/patches/ with some headers" a defined interface?
> > It's an interface, that if you stop there in defining it, means that I
> > have to check debian/patches/ into revision control, and bloat my
> > .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> > with them.
> You don't have to check it in revision control, you just have to be able
> to generate them from revision control.
> For .diff.gz, we already have tools to handle such files properly
> (without duplicating their content), it's called quilt or simple-patch-sys
> of CDBS and you know it (but you don' like those).
> For .git.tar.gz, if you have a tool to generate the patches, it would be
> possible to hook it into the automated system that uploads patches to
> patches.debian.org. If that process is not the same across all
> .git.tar.gz, we can mandate a new debian/rules target that must generate a
> debian/patches directory with all the patches.
Note how infrastructure needs would decrease considerably if packages
were mandated to use v3(quilt) format: patches.debian.org would be
ftp.debian.org and would just need nothing new (except for how source
packages are created)