Bug#1007717: Native source package format with non-native version
Sam Hartman <firstname.lastname@example.org> writes:
>>>>>> "Russ" == Russ Allbery <email@example.com> writes:
> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures "is a packaging of an upstream
> Russ> software package with a separate existence" versus "exists
> Russ> solely as a Debian package." "with-revision" or
> Russ> "without-revision" doesn't feel to me like it does this.
> Russ> Native and non-native do, which is why I was sticking with
> Russ> them, but maybe we can come up with some other equally-good
> Russ> terminology.
> Why do we need that distinction?
I think we need some way to talk about the various things that change
about a package if it is a packaging of an upstream package. Examples
include a debian/watch file, an upstream metadata file, an upstream
signing key (still useful with single-tarball formats if upstream uses
signed tags, etc.), and provenance information in debian/copyright.
Those things are not tied to the source package format. We want
provenance information for the upstream source even if you're using a
single tarball as a source package format, but we don't need it if there
is no upstream.
> Looking at current policy, 5.6.12 talks about having a debian revision
> or not having a debian revision.
It seems less useful to me to frame this solely in terms of the version
number format, rather than having the version number format indicate
whether this is a packaging of an upstream source with an independent
existence. That would imply that if you just omit the debian revision,
you don't need to record the provenance of the upstream source, which
doesn't seem correct.
Russ Allbery (firstname.lastname@example.org) <https://www.eyrie.org/~eagle/>