Sean Whitton writes ("Bug#1107137: Distinguish "native source packsge" from
"native version number""):
> You've replaced or removed some wording which seemed to me to be
> helpful. For example,
Thanks for the review. But...
Your mail doesn't say which files your quotes are from in nor give the
context. Nor does it quote the new text. So I had to go back and
forth between the base an tip of my git branch to find out which patch
hunks you're talking about.
Does your mail client have the ability to quote a diff hunk from one
of my patch attachments? I think we should use a workflow that
encourages responding to hunks where appropriate. Traditional PATCH
email workflow does that; git forge online review does too.
Anyway...
The whole point of this series is to distinguish the two concepts of:
- native vs non-native version numbers
- native vs non-native source package formats
which is necessary to reflect reality (and the TC decision).
> A native source package is one that does not distinguish between
> Debian packaging releases and upstream releases
This old text is in ch-source.rst. But it talks about "releases"
which is ambiguous: do we mean version numbers or representation in
the physical source package?
It therefore needs to be replaced with something that is clearly soley
about source package format and not about version numbers. It can't
be retained as-is.
> seems to me at least if not more explanatory than talking about
> "separate versioning", and
This appears to be a quote from my new text in ch-versioning, which is
therefore about version numbers.
I'm not sure how I can respond properly to this comment since it seems
to be (re)conflating these two concepts and/or their two principal
locations in the document.
> there may be multiple Debian package versions associated with a
> single upstream release version and sharing the same upstream source
> tar files.
Again this is the old text in ch-source.rst. Again, this old text
conflates source package format with versiooning. "Associated" is
imprecise.
> seems easier to understand than
>
> Successive updates to the package within Debian, based on the same
> upstream version ...
This is a quote from my new text for ch-controlfields.rst. So this is
not supposed to be a direct replacement for the text above.
> (in particular, "upstream version" is ambiguous between "version of the
> upstream source" and "upstream version number" in this sort of context;
> I'd suggest avoiding it).
I do add some uses of "uptream version" that mean "the package as it
comes from upstream". I agree that this could be confusing.
I'm happy to change it to something else. We could use "upstream
release" but of course that assumes that every upstream version in
Debian corresponds to something that upstream think of as a release,
which is wrong in a different way.
How about "upstream source" ? Ie
+...
+that this package is derived by
+Debian from upstream source code which is maintained independently,
+...
Patch for that change attached.
> Also, you removed and them re-added "Most source packages in Debian are
> non-native." between patches in the series. I'm not sure why that was
> done but I would also like to suggest replacing it with "Most source
> packages in Debian use non-native version numbering." because that seems
> to me like the more important point.
I didn't intend to change this as part of this work. That I did so
was an oversight.
Thanks,
Ian.
--
Ian Jackson <ijack...@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.
>From 3b6e3b6c6e8bdfbcae5c38095e45f0102fffb20b Mon Sep 17 00:00:00 2001
From: Ian Jackson <ijack...@chiark.greenend.org.uk>
Date: Sun, 22 Jun 2025 18:34:54 +0100
Subject: [PATCH 5/5] Prefer "upstream source [code]" to "version" or "release"
---
policy/ch-controlfields.rst | 4 ++--
policy/ch-source.rst | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 433d67a..8886316 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -605,9 +605,9 @@ is no separate upstream, and the package's primary
maintenance is
within Debian.
The ``debian_revision`` indicates that this package is derived by
-Debian from an upstream version which is maintained independently,
+Debian from upstream source code which is maintained independently,
outside Debian. Successive updates to the package within Debian,
-based on the same upstream version, have the same version number
+based on the same upstream source, have the same version number
except for the ``debian_revision``. This is called a **non-native
version number**, or (informally) a "non-native version" or "non-native
package".
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 0e55c09..2ac67ef 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -19,7 +19,7 @@ single tar file of source material. Native packages are
normally (but not
exclusively) used for software that has no independent existence outside
of Debian, such as software written specifically to be a Debian package.
-A **non-native source package** separates the upstream release from the Debian
+A **non-native source package** separates the upstream source from the Debian
packaging and any Debian-specific changes. The source in a non-native
source package is divided into one or more upstream tar files plus a
collection of Debian-specific files. (Depending on the format of the
--
2.47.2
