Hi!

[ I'm exhausted and tired about this topic, and the previous and recent
  litigiousness and confrontational vibe surrounding it all, which has
  been dragging on for years. So for some of the following stuff, I
  cannot be bothered to recheck or provide links and references. Sorry. ]


Summary
-------

Given the previous bogus advice the TC provided, and that I've been told
a new ruling would follow that, to try to reduce the chance of making
the surrounding code area a "toxic wasteland" with uncertainties on what
can be changed or not w/o having to consult the TC every time (which I'd
rather not interact with at all), I've committed a change to dpkg git main
that makes the «3.0 (native)» source format be "fuzzy native" for Debian
and derivatives. This will be in principle part of dpkg 1.23.0 (in Debian,
targeting forky). (This also deprecates the Dpkg::Version->is_native()
method which can no longer be portably used with consistent/coherent
semantics, to be removed at a later point.)

Where I guess this broken new notion will keep being pushed either in a
litigious way or similar (and where the «3.0 (native)» format might become
a «toxic wasteland» of development uncertainty (in Debian and derivatives)
anyway (where I assume it will not be worth modifying further). I'm
assuming (that's why this filing) the Debian policy will need to be
adapted too to this new reality. See below.


Background
----------

This has been covered on some dpkg (#700177, #737634), policy (…),
lintian (#944155) and tech-ctte bugs (…), and several threads on d-d
over the years where my position was
<https://lists.debian.org/debian-devel/2014/02/msg00102.html>
<https://lists.debian.org/debian-devel/2019/11/msg00073.html>
<https://lists.debian.org/debian-devel/2019/11/msg00081.html>.

When the consistency and coherence check was introduced for 3.0 formats,
this affected:

  - 0 packages in «3.0 (quilt)» format.
  - 9 packages in «3.0 (native)» format, most of which seemed like
    accidental packaging mistakes.


For 1.0 format(s), this is the classification of the affected packages
over time:

  - Current affected packages (10), and maintainers (6):

    ,---
    $ Sources=$(apt-get indextargets \
                --format '$(FILENAME)' 'Identifier: Sources')
    $ /usr/lib/apt/apt-helper cat-file $Sources | grep-dctrl \
        -n -sPackage -FFormat '1.0' -a \
        -FVersion '-' -a --not -FFiles '.diff.'
    chiark-tcl-applet
    chroma
    python3-defaults
    rust-derive-deftly
    spigot
    sympathy
    userv-utils
    valgrind-if-available
    xbs
    xtruss
    `---

  - Accidental packaging mistakes:

    + Most might have been fixed due to the lintian tag introduced later,
      some due to the dpkg-source warnings introduced even later, the rest
      due to bugs being filed. From me for example at:
      <https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=dpkg-mismatch-source-vs-version-format;users=debian-dpkg@lists.debian.org>
      and #947051, but other people might have filed similar reports.

  - Metapackages, where the intention is to track another upstream
    versioning schema, but from a native package (which can be handled via
    version remapping for src→bin pkgs), there are only a handful of these
    that I'm aware of.

  - Workflow "reasons":

    + In-archive use, due to a handful of maintainers, that primarily use
      git based workflows, where some even consider that source packages
      are a relic and should be completely abolished. There has also been
      incorrect reasons given in the past such as claiming «3.0 (quilt)»
      not supporting git formatted patches (those have been supported
      since GNU patch(1) gained support for them, which was made a hard
      requirement for dpkg).

    + Out of archive use, like in git based workflows or CI settings when
      building out of git, where alternatives have been suggested in the
      past, such as using «git archive», pristine-tar (which I'm not a fan
      of) or pristine-lfs, or via the «3.0 (git)» or «3.0 (custom)» formats,
      or even using a different «-» character instead of abusing the
      revision marker, but the complainants have refused all of those
      (clearly misusing the format is more convenient, in detriment to
      everyone else).
      <https://lists.debian.org/debian-devel/2022/03/msg00176.html>


Because the 1.0 format(s) are sloppy and their behavior is context
sensitive based on whether specifically named tarballs might be around,
or depending on the dpkg-source options given, there was an implicit
compromise on allowing this incoherence and inconsistency for that format
in its "native form" while still emitting a warning, until a new source
format, an existing one could be improved, or better tooling or workflows
could be implemented or devised. This compromise was made explicit on
the "recent" mass bug filing thread on d-d:

  <https://lists.debian.org/debian-devel/2022/03/msg00285.html>


There was never a reply to the dpkg bug report after the TC involvement
(except for <https://lists.debian.org/debian-dpkg/2023/11/msg00013.html>),
because I never found the energy to engage with it afterwards, given
the litigious and contentious discussions this involved, and because
it's hard to find the motivation to, say, devise a new source format,
or improve the surrounding tooling or an existing source format, when
the vocal people that have been pushing for this, seem to either only
want to use this because their CI requires them to (and are not willing
to consider any of the proposed alternatives), or think that source
packages should be completely abolished anyway, or where for the
metapackages case this would be used by a handful of packages in the
archive at most anyway.

  <https://lists.debian.org/debian-devel/2022/03/msg00173.html>


Actions
-------

In the Debian context, this pushed confusion also seems clearly
against its policy, so from the Debian policy side, I guess you'll need
to scrap or heavily reword at least most of §4, and parts of §3.2.1,
§12.7, §5.6.12, §5.6.12.2.

So, I guess you'll need to mention or document somehow, somewhere
that the native concept is fuzzy, and that, well, in Debian and
derivatives, it does not have much of a real meaning anymore going
forward.

After that, I guess someone should probably go around fixing at least
devscripts and dgit (which are using Dpkg::Version, I don't know about
other stuff using other language bindings, or using their own parsing,
etc), and anything else expecting (as it would be logical) that a native
version implies a native source package, which might need to be made
aware of source specific formats (in case that information is even
available at all).

Someone might also want to add some new questions to the NM templates
(if these are not already there), as in stuff like:

  - "what is a native source package?"
  - "what is a native version?"
  - "can a native source package have a non-native version?"
  - "can a non-native source package have a native version?"
  - "why?"


Consequences
------------

I'm assuming that once this lands in dpkg in Debian, we'll start to get
new regressions, for the convenience of being able to abuse the concept
while undermining these source package formats, for the benefit of people
that seem to be using them in anger and would rather see them gone anyway,
where the existing warnings have been shown to not be enough, and where
people seem to miss them.

I'll stop tracking these recurring mistakes, as I can't be bothered
anymore.

This makes the native source concept, have incoherent and confusing
meaning/semantics, and it stops being symmetric with non-native source
packages. Where one of the usual complaints people have over the dpkg
tooling and packaging system and stack in general, and its concepts is
that they are too complex, so I guess this goes into making it even
more confusing and incoherent.


Going forward
-------------

I've also been pondering about native source for a while, and I guess this
is the last drop in the bucket, and I'm going to be strongly considering to
stop using it for packages I maintain. It does not support upstream
signatures (and downstreams not on a dpkg-based distro do not have much of
a use for signed .dsc); the NMU rules for native sources still look very
wrong to me, because they take over the "upstream" versionspace, as if it
was an official/supported release, when such NMUs should be switching to
a non-native format; in a similar vein, downstream tend to patch the native
source as is, instead of switching it to a non-native format, which makes
the delta, non-obvious, and also takes over the versionspace, and further
complicates its own downstreams which could otherwise more easily choose
to opt out of specific changes.


I'm still convinced this is wrong, sloppy, and adds confusion and
incoherence, for both tools and humans, that's why the dpkg code still
considers this an error for non-Debian and non-Debian derivative vendors
(where I've now used the opportunity to also make the 1.0 source format
case a hard error there, given that the compromise has been broken
anyway and this is vendor specific now), but for Debian and derivatives,
I cannot be bothered anymore. Someone else will need to handle any
possible fallout now, and going forward…


[ I'm very unlikely to engage further on this topic. ]


Whatever,
Guillem

Here is what I think needs to be done to policy to reflect the TC
decision in #1007717.  That decision implies that source package
nativeness and version number nativeness are at least partially
decoupled, so we need to speak more precisely about which we mean.

I chose the terminology "[non-]native source package" and "native
version [number]".  I think we can generally continue to use "native
package" when we are speaking loosely, or when it's not ambiguous.

I considered "[non-]native source package format" but that's
confusing, because while 1.0-native and 1.0-with-diff are in this
sense different formats, dpkg-soruce has debian/source/format which
conflates them.

I've explicitly stated that non-native source formats can't be used
with native versions.  I don't think such a thing could function.

Ian.

Hello,

Thanks, I'll review this.

Hi!

While the policy should, of course, not mention any specific packages,
I think it would be prudent to try to justify the suggested changes
with practical examples of packages using the versions in the ways you
describe.

Your text indicates that you want to continue using source format 1.0
for some packages, even though Debian deprecated it a long time ago
(https://trends.debian.net/#source-formats). That does not make sense
to me, but it is difficult to provide counter-arguments on what is the
proper way to do something in lack of concrete examples.

This is also a case where both the suggester and reviewer (Ian and
Sean) are both biased in getting rid of source packages in Debian and
you both have a vested interest in promoting use of the source format
version 1.0 in ways that previously were considered misuse. By
rewriting the policy you can make it suddenly be "correct" to ignore
basic assumptions the entire Debian archive is built upon.

Thus I am requesting that these changes are properly justified with
supporting examples of packages that really need it.

Thanks!

Hi!

Due to how Gulliem expresses himself I find it hard to follow what the
core argument or request here is, but looking at the examples one can
slowly piece together what is special about them:

The topic seems related to Ian's drive to start using the 1.0 source
format again for new packages, like he did in xtruss, despite my
recommendation and ignoring the example of how the same can and should
be done with format 3.0
(https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/396).

I suggest the changes in this Bug#1107137 would be postponed for now
and the format discussed at the next DebConf.

Otto Kekäläinen <otto@debian.org> writes:

This is already discussed at some length in the TC bug cited earlier in
this bug (#1007717).

This change has nothing to do with eliminating source packages. I'm not
entirely sure what you're talking about in the second part of your
sentence, but if I understand you correctly, your contention is contrary
to the relevant TC decision.
assumption. People have been using native 1.0-format packages this way for
as long as I've been involved in Debian. This debate, which has been going
on for at least ten years (thus indicating there was no settled project
consensus), was always about whether we should eliminate those uses, and
while there have been various arguments in favor of doing so, we never
decided as a project to do so (and in fact the TC decided the other way).

With my Policy Editor hat on, I don't believe anyone needs to produce
further justification of that type to evaluate this proposed change.
Policy follows TC decisions. We do not have leeway on this; the TC is the
constitutional body empowered to make those decisions. If you don't like
the TC decision, you need to take that up with the TC, not here.

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 <ijackson@chiark.greenend.org.uk> writes:

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.)

This part seems fine.

Possibly add:

    and non-native source packages can have native versions (but this is
    rare).

although I'm not sure.

Given the above, I'd also drop the i.e. here.

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.

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.

Hello,

No reason why we can't both review it!  I'll wait until Ian has
responded to your review before doing mine.

There is clearly consensus that source format 1.0 is deprecated. This
is evident by the fact that in the past 10 years the usage of source
format 1.0 has gone down from 10000+ to 158
(https://trends.debian.net/#source-formats). So the discussion in
"past 10 years" you refer to already had a clear outcome.

Hi,

Otto Kekäläinen <otto@debian.org> writes:

I disagree - the TC ruled in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717#384 that
(inter alia):

  1. It is not a bug of any severity for a package with a non-native
     version number to use a native source package format.

  4. We believe that there are indeed circumstances in which
     1.0-with-diff is the best choice for a particular source package,
     including, but not limited to, git-first packaging workflows.
     However, we recommend discontinuing use of 1.0-with-diff in other
     circumstances, to simplify the contents of the archive.

     This is because there is currently no other source format which is
     such that avoid both (i) uploading the whole source, including
     upstream, for every upload; and (ii) having to maintain
     debian/patches/ inside the package tree.

As Russ observed elsewhere, Policy needs to follow the TC ruling. This
bug is not the place to re-argue that TC discussion.

Regards,

Matthew

Hi,

I checked a couple of those 158 remaining packages and I noticed you
are among those who are using this 1.0 format intentionally. You
should be honest that you have been doing this already before the TC
accepted Ian's proposal to rule that 1.0 format is acceptable, and the
TC decision is not the reason you do this, but the permission for you
to continue.

I skimmed through the discussion in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717 and that
discussion too is void of examples of packages. This statement "there
are indeed circumstances in which 1.0-with-diff is the best choice for
a particular source package" in the resolution isn't actually backed
up by examples, which worries me. Assuming Ian is the best proponent
of using this format, we should look at one of his packages and ask if
it really is the "best choice". Looking at
https://tracker.debian.org/pkg/xtruss it was uploaded as a native
package with Debian revision, and the only artifacts in the Debian
archive are xtruss_0.0~git20241011.27fafffe-1.dsc and
xtruss_0.0~git20241011.27fafffe-1.tar.gz. There is no upstream xtruss
source at all. Getting rid of upstream source packages seems to be the
goal of Ian, but the TC decision to allow it was using wording that
seems to deliberately avoid mentioning that this is indeed the
outcome.

Having examples of real packages as part of the discussion would make
it more obvious what is the actual result of the suggested changes in
policies and rules.

Hello,

Otto, as Matthew and Russ noted, this Policy bug isn't the place to
dispute the TC's decision.  Please don't continue to do that here.

Otto Kekäläinen <otto@debian.org> writes:

Stating that there is consensus for something when the TC has made a
contrary ruling feels incorrect within Debian's governance process.

We have a constitutional mechanism for making this decision and at present
that mechanism has produced a decision that does not say this. Instead, it
said:

  4. We believe that there are indeed circumstances in which
     1.0-with-diff is the best choice for a particular source package,
     including, but not limited to, git-first packaging workflows.
     However, we recommend discontinuing use of 1.0-with-diff in other
     circumstances, to simplify the contents of the archive.

     This is because there is currently no other source format which is
     such that avoid both (i) uploading the whole source, including
     upstream, for every upload; and (ii) having to maintain
     debian/patches/ inside the package tree.

This falls short of a general deprecation. It is, at most, a deprecation
for specific workflows.

1.0 (native) is a separate case, and I am somewhat more inclined to agree
with you on that subset of your statement, but only because 3.0 (native)
is now usable for the same purpose. Prior to Guillem's recent change, it
was not possible to use 3.0 (native) for non-native packages, which meant
that 1.0 (native) was the only choice for single-tarball source packages
for non-native packages. That implies that it can't be deprecated because
of the TC ruling:

  1. It is not a bug of any severity for a package with a non-native
     version number to use a native source package format.

Now, perhaps it can be because we have forward progress on:

  2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
     complain, when a non-native version number is used w/ 3.0 (native).

Policy is going to follow TC decisions unless they are overruled by a GR.
This is part of what I agreed to when I agreed to follow the Debian
constitution when I became a Debian Developer. If someone doesn't like a
TC decision, they should take it up with the TC or propose a GR, not try
to argue against it in Policy.

I'm happy to discuss the merits of the decision in a TC bug if you want,
since I do have my own separate personal opinions [1], but once the TC has
made a decision on a matter of technical policy, the scope of Policy is
limited to trying to correctly interpret and integrate that decision.

[1] Sneak preview: none of the subsequent discussion has substantively
    changed my opinion as expressed on the original TC bug in 2022:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717#50

You are confusing 'unpopular' and 'deprecated'.

Cheers,

Hi,

I agree with pretty much everything you wrote back then. In particular,
I find your proposal still relevant:

I think this is covered by the TC decision. If not, we should make it
so.


Cheers
Timo

Russ Allbery writes ("Bug#1107137: Distinguish "native source packsge" from "native version number""):

This text seems great to me.

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.

Non-native source packages with native versions cannot function.  I'm
pretty sure no-one is doing that.

You're probably right.

I think I kept it somewhere?  I'll double check.

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 <ijackson@chiark.greenend.org.uk> writes:

Yeah, I think that's what I'd prefer. My belief from past discussions is
that there isn't a project consensus for ruling out the less-used
combinations because there are certain circumstances in which they're
quite useful, although there are a substantial number of people who don't
like those exceptions and would prefer we push people into a narrower
range of options.

Oh, yes, this is me stumbling over the definitional problem again. Not for
this change, but I really wish we had less ambiguous terminology. It is
incredibly hard (at least for me) not to mix up the three concepts here:

* Non-native maintenance (there is an upstream independent of Debian and
  the Debian package is a packaging of that upstream).

* Non-native package (the packaging splits the upstream source from the
  Debian packaging and modifications)

* Non-native version (the package version has a debian_revision component)

I was thinking of native versions with non-native maintenance, and then
wrote native versions with non-native packages, which you are of course
correct is impossible. Your text is good here.

Russ Allbery writes ("Re: Bug#1107137: Distinguish "native source packsge" from "native version number""):

I was thinking about this and the latter sentence isn't necessarily
true.

Suppose the Debian and upstream maintainers are different people, with
different responsibilities, but they coordinate well and they work in
the same git branch.  The Debian maintainer might not do an upload if
upstream makes changes that don't have any effect in Debian; and the
upstream maintainer might not do an upstream release for changes that
only affect Debian packaging.  This would all work, but it would mean
that there might be upstream releases with Debian upload and vice
versa.

I'll go with

   Often this is because there is no separate upstream, and the
   package's primary maintenance is within Debian.

which I think is both vague enough to be true and definite enough to
be useful.

Done.

Apparently I did indeed accidentally delete this.  I have restored it.

This implication would be true in the forward direction, but not the
latter.

Rather than trying to restate everything fully again, I have written
this:

  - The absence of ``debian_revision``, and therefore of a hyphen in the
    version number, indicates a non-native version: the package has
    no separate versioning in upstream versus Debian.  See
    :ref:`s-native-version`.

Attached is the fixup! commit I've made.  It autosquashes cleanly.
I'll follow up with a re-attachment of the whole 4-patch series.

Ian.

Ian Jackson writes ("Re: Bug#1107137: Distinguish "native source packsge" from "native version number""):

The Wanderer writes ("Re: Bug#1107137: Distinguish "native source packsge" from "native version number""):

Ian.

Note: Wanderer wrote to me privately citing some kind of email
trouble, but gave permission for me to replyh in public.

Ian Jackson writes ("Re: Bug#1107137: Distinguish "native source packsge" from "native version number""):

Whole series with "non-" nsense fixed.

Ian.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Good point.

Yeah, that seems fine to me.

Yes, that looks good to me.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

Looks good to me. Seconded.

Hello Ian,

You've replaced or removed some wording which seemed to me to be
helpful.  For example,

    A native source package is one that does not distinguish between
    Debian packaging releases and upstream releases

seems to me at least if not more explanatory than talking about
"separate versioning", and

    there may be multiple Debian package versions associated with a
    single upstream release version and sharing the same upstream source
    tar files.

seems easier to understand than

    Successive updates to the package within Debian, based on the same
    upstream version ...

(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 would suggest putting the older phrasings back.

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.

Sean Whitton <spwhitton@spwhitton.name> writes:

I'm fine with *also* saying the latter, but I would like Policy to
continue to say the former. I think it's helpful for readers of Policy to
be told explicitly that the non-native source package case is the normal
case and therefore the case they should be paying the closest attention to
if they want to understand the current archive.

Sean Whitton writes ("Bug#1107137: Distinguish "native source packsge" from "native version number""):

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).

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.

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.

Again this is the old text in ch-source.rst.  Again, this old text
conflates source package format with versiooning.  "Associated" is
imprecise.

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.

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.

I didn't intend to change this as part of this work.  That I did so
was an oversight.

Thanks,
Ian.

Hello,

Mentioning both makes sense to me, too.

Hello,

That's what I normally do, and there was no particular reason I didn't
do it this time.  My apologies.

Ah.  If you make it "making a Debian package release and making an
upstream release" then I think that removes the ambiguity.  That is how
I was implicitly reading it, I think.

I don't see how this conflates source package format with versioning.
So far as I can see, it only talks about versioning.

Okay, then forget about this part, I misunderstood it as being a
replacement.

The fact that we sometimes package non-releases seems minor and not
worth complicating things over, but using "upstream source" to avoid it
is fine with me.

Sean Whitton writes ("Bug#1107137: Distinguish "native source packsge" from "native version number""):

Well, I tried drafting a substantive reply to these comments but it
didn't seem to come out very usefully.  The bottom line is that I
still prefer my wording.

Patches 1-4 have been seconded by Russ.  I'm hoping patch 5 isn't
controversial.  Could I have a second for the revised version of the
series?

That is,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107137#112
    patches 1-4
plus
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107137#137
    patch 5

Thanks,
Ian.

Patch 0001: Looks ok to me.

For patch 0002:
I do not like this as we now end up with:

  * "native package" is about the version (first paragraph)
  * "native source package" is **not** about the version
    (second paragraph).

For me, this is inviting term confusion and I would recommend we avoid
the `native package` term like the "plague" if this is our definition of
that term.
   Even if there is a compelling reason to mention `native package`, my
recommendation is to avoid the term in the primary text. Such as moving
the usage of the term to a foot note instead with a remark that the term
is a historical usage only and will no longer be used due to proximity
to "native source package" that has a different definition.



Patch 0003: Looks ok to me.

For patch 0004:  Same remark as I had for 0002 on "native package" vs.
"native source package".

Also, typo (`non-versons`) in the following paragraph. Did not see an
obvious mention of this being fixed in the bug log, so assumed it was
still there.

Patch 0005: Looks ok to me.

Best regards,
Niels