I know Sean said that he is reviewing this diff and this is not intended to replace that. I'm just jumping in because I'm familiar with most of the background here and noticed a few things.
Ian Jackson <[email protected]> writes: > +.. _s-native-version: > + > +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. 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.) > +The ``debian_revision`` indicates that this package is derived by > +Debian from an upstream version which is maintained independently, > +outside Debian. Successive updates to the package within Debian, > +based on the same upstream version, have the same version number > +except for the ``debian_revision``. This is called a **non-native > +version number**, or (informally) a "native version" or "native > +package". 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. > -A native source package is one that does not distinguish between Debian > -packaging releases and upstream releases. A native source package contains a > -single tar file of source material, and the versioning does not have a > -Debian-specific component. Native packages are normally (but not > +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. > -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. > - 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? The other changes look good to me. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
