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

Emmet Hikory emmet.hikory at
Wed Jan 9 20:59:49 GMT 2008

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.

    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.

    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.

    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.


More information about the ubuntu-devel mailing list