Call for discussion: Migrating from interdiff to diff.gz for new upstream sponsoring

[Scott Kitterman]

On Wednesday 09 January 2008 15:59, Emmet Hikory wrote:
> On Jan 10, 2008 1:59 AM, Scott Kitterman wrote:
> > I like diff.gz better than interdiff.
> >
> > Perhaps a diff of the debian/dirs would be even easier (Changes outside
> > the debian dir that need to be maintained should be patched).  Then the
> > sponsorship work flow would be something like:
> >
> > 1.  Get the current source package.
> > 2.  Get the new upstream based on the watch file (uscan)
> > 3.  Review the provided 'patch' to the debian dir
> > 4.  Apply the patch
> > 5.  Build, Test, Etc.
> >
> > Anythiing in diff.gz outside the debian dir that needs to be preserved
> > from release to release should be dealt with as a special case.
>
>     There are a signficiant number of packages in the archive that do
> not use a patch system, and in many cases, the Debian Maintainer has a
> strong reason to not do so.  The most common seems to be using a VCS
> compatible with upstream including the full upstream source for
> packaging, and maintaining patches in the VCS for better coordination
> with upstream.

Fair enough.  

>     In the interests of not creating greater variance with Debian,
> increasing the chances that we can later sync any new upstream
> packages with Debian, and being able to handle special cases (e.g. a
> patch is required to run $(MAKE) clean), a solution that does support
> changes external to debian is preferred.

Makes sense.

>     Also, regarding point #2, uscan doesn't work for all packages:
> many upstreams don't distribute in .tar.gz format, some packages
> require removal of non-free data, and some packages do not include a
> version string in the upstream release file.  To support this, it may
> be better to use `debian/rules get-orig-source || uscan
> --force-download` to pull the new upstrem version, rather than just
> the watch file.

OK.

>     Lastly, a number of packages have issues with the current watch
> file or get-orig-source (although this number is decreasing), so it
> may be preferable to use the watch file or get-orig-source rule from
> the new candidate, rather than that from the existing package.  It may
> be better to review the diff and apply the patch prior to collecting
> the new upstream tarball, just to take advantage of any improvements
> in the collection rules in these cases.

Yes.  I've had to do this myself.  The sponsorship workflow was meant to be an 
example.

OK.  I'm convinced then.   Diff.gz is good.

Scott K