Re: dpkg: is_native version checks in dpkg 3.0 Native

[Sam Hartman <hartmans@debian.org>]

>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:

    >> Citation requested.  I looked for this today and couldn't find
    >> it.

    Russ> Policy lacks a section that clearly defines native and
    Russ> non-native packages, which is a long-standing bug in Policy.
    Russ> Currently, that information is in Policy 5.6.12, which is an
    Russ> inobvious place for it, and worse, is hidden in the definition
    Russ> of the debian_revision component.  However, the intent is to
    Russ> define native vs. non-native by the version number format
    Russ> used:

OK, we found the same section of policy.

    Russ>     This part of the version number specifies the version of
    Russ> the Debian package based on the upstream version. It may
    Russ> contain only alphanumerics and the characters + . ~ (plus,
    Russ> full stop, tilde) and is compared in the same way as the
    Russ> upstream_version is.

    Russ>     It is optional; if it isn't present then the
    Russ> upstream_version may not contain a hyphen. This format
    Russ> represents the case where a piece of software was written
    Russ> specifically to be a Debian package, where the Debian package
    Russ> source must always be identical to the pristine source and
    Russ> therefore no revision indication is required.

OK.
I agree that policy 6.5.12 clearly states that if the debian revision is
absent:

* The software is written for Debian

* the source and upstream source must be the same

* No revision is required (i think this last is analysis not normative)

However, I cannot read that text to imply anything about what happens if
the Debian revision is present:

* Policy seems silent on whether the software MAY?SHOULD NOT/MUST NOT be
  written explicitly for Debian (I consider this a feature)

* Policy appears silent about whether the source and upstream source are
  the same/need be the same

* Policy seems very silent about whether technical mechanisms that would
  make it difficult for the upstream source and source to differ are
  appropriate with a debian revision present.
Clearly, if your source and upstream source differ, using technical
  mechanisms incompatible with that is nonsensical.

I claim that 6.5.12 at least is silent on the treatment of packages that
have a Debian revision.  

I agree that 6.5.12 strongly suggests that
3.0(QUILT) packages should have a debian revision.  Any thought at all
about 3.0(QUILT) raises that to a requirement rather than a strong
suggestion.
However that seems unrelated to this bug.