Hi,

Sam Hartman wrote:

> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision is incremented for packaging only changes and upstream
> revision is incremented for upstream versions
>
> and
>
> 2) Cases typically outside the Debian archive where a git tree is being
> built as a Debian package especially as part of a CI system and where
> the effort of tracking upstream tarballs is undesired.
>
> 2) is more of an issue for lintian than it is for debian-policy.

I don't have any strong opinions about this, but I got the impression
that Ian's motivation is a different case 3):

| Most packages are maintained in git nowadays.  It is usual to have a
| separate git branch for Debian and upstream work.  In such a situation
| it makes perfect sense to have an upstream version number which
| corresponds to an upstream tag.  For packages with a very small (or
| zero) Debian delta to the upstream files, it makes sense to maintain
| these git branches using `git merge' rather than as a stack of
| patches.
|
| However, there are serious inherent problems with all of the
| non-native source formats.  There are many that can occur in git
| repositories which are not representable in non-native packages.  For
| example, changes to symlinks.  Worse, one must either choose
| `3.0 (quilt)' which involves patch files within the git tree
| and a great deal of complexity to manage those; or 1.0-with-diff which
| has an even more restricted set of things it can represent.

Regardless of what happens to the 1.0 format, shouldn't the non-native
package formats be improved to handle this?  The "git diff" format,
which GNU patch has reasonable support for, is able to represent all
of these kinds of changes, including changes to symlinks.  Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time.  To the extent that this
doesn't work, it seems worth fixing.

Thanks,
Jonathan

Reply via email to