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

Re: How to handle Debian patches



On Sun, May 18, 2008 at 04:54:28PM +0200, Lucas Nussbaum wrote:
> On 18/05/08 at 16:48 +0200, Mike Hommey wrote:
> > On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
> > > On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
> > > > 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[1] 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)
> > > 
> > > No, you would need to untar the .debian.tar.gz file, so upstream can
> > > browse the patches.
> > 
> > And? You also have to untar the source .tar.gz from upstream web site...
> 
> It sounds better to be able to tell upstream:
>    patch available from http://......./the_patch.diff fixes that.
> Rather than:
>    patch the_patch.diff  in http://...../foo.debian.tar.gz fixes that.

It sounds better to send the patch directly instead of telling upstream
to go to some random place to gather it.

Mike


Reply to: