Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages
Jonathan Nieder writes ("Re: debian-policy: Please permit Debian revisions with 1.0 native packages"):
> 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):
I agree with both of Sam's motivating scenarios. But I also agree
with you that I presented a different scenario:
> | 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.
[emphasis added]
> 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.
Well, maybe. I agree that some improvement here is warranted, but it
would need a transition plan to avoid uncontrolled adoption of source
package features meaning that source packages unexpectedly cannot be
unpacked on older releases of Debian.
But that does not solve the problem for my scenario. I wrote:
| *which involves patch files within the git tree
| and a great deal of complexity to manage those*
I do not agree with the thrust of your comment that "Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time". It's true as far as it
goes but doesn't address the key problems, namely that the single
patch ends up inside the tree.
This could be solved by a new `3.0 (diff)' format perhaps. If and
when that is provided then this one scenario would perhaps be better
handled that way. But we are not there yet.
The other two scenarios presented by Sam would still remain as reasons
to have a native package with a hyphen in the version number.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Reply to: