Russ Allbery writes ("Bug#1107137: Distinguish "native source packsge" from
"native version number""):
> > +Native vs non-native version numbers
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +When the ``debian_revision`` is absent, the package's primary
> > +maintenance is within Debian.
>
> Based on the many past discussions of this, I'm fairly sure this statement
> isn't true. Every time we've had a round of this discussion, some people
> have come forward to say that they are upstream and upstream is separate
> and primary, but they choose to have a one-to-one correspondance between
> Debian versions and upstream versions anyway for some reason (usually
> their own convenience and preference as upstream maintainer), and are
> happy to accept the consequence (a new upstream release for every Debian
> maintainer upload).
>
> I believe the only thing we can accurately say about this situation is
> something more like:
>
> When the ``debian_revision`` is absent, there is no separate
> versioning of maintainer uploads of the Debian package and an upstream
> release. Either there is no separate upstream and the package's
> primary maintenance is within Debian, or maintainer uploads of the
> Debian package correspond one-to-one with upstream releases.
This text seems great to me.
> We might want to recommend against the latter approach because it tends to
> cause problems if upstream maintenance changes, but maybe that's more of a
> developers' guide thing? (And I'm not sure it really causes that many
> problems; the package just becomes non-native, which isn't that painful as
> I recall.)
Changing either source formats and/or version numbering to or from
native works fine and doesn't cause any trouble, assuming that the
version numbers are chosen reasonably sensibly. So I don't think it's
a practical problem.
You make very good points above, which lead me to think recommending
against these practices may be controversial. It would be eaiser just
to state the things that are definitely implied.
> This part seems fine.
>
> > +Native version numbers and native source packages (see
> > +:ref:`s-source-packages`) often go together, but native source
> > +packages can have non-native version numbers.
>
> Possibly add:
>
> and non-native source packages can have native versions (but this is
> rare).
>
> although I'm not sure.
Non-native source packages with native versions cannot function. I'm
pretty sure no-one is doing that.
> > +A **native source package** contains a
> > +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.
> > +of Debian, such as software written specifically to be a Debian package -
> > +i.e., packages with native version numbers.
>
> Given the above, I'd also drop the i.e. here.
You're probably right.
> > -Most source packages in Debian are non-native.
>
> This sentence remains true and I don't want to lose it. This helps the
> newcomer to Debian who may have been confused by all this stuff by
> steering them towards non-native packages as the common case, which I
> believe is correct.
I think I kept it somewhere? I'll double check.
> > - The absence of ``debian_revision``, and therefore of a hyphen in the
> > - version number, indicates that the package is native.
> > + version number, indicates that the package has no separate upstream
> > + maintainers, and is simply maintained by Debian. See
> > + :ref:`s-native-version`.
>
> Here too, I don't believe this is true. We can say something along the
> lines that the Debian packaging does not separate upstream from Debian
> changes, maybe?
I'll reword this.
Any further comments from anyone?
If not I'll respin the series and send a new mail with updates.
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.
