Bug#986320: Stronger advice on when to use native packages

[Sam Hartman <hartmans@debian.org>]

>>>>> "Sean" == Sean Whitton <spwhitton@spwhitton.name> writes:

    Sean> Hello,
    Sean> On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote:

    >> To be clear, my understanding of the advocacy of using non-native
    >> packages is primarily about their impact on *Debian* workflows
    >> (being able to base multiple packages on the same tarball, not
    >> introducing confusion between upstream version numbers and Debian
    >> version numbers and thus making it easier for other people in
    >> Debian to track the package to an upstream version, triggering
    >> various package checks that ignore native packages but care about
    >> non-native packages such as uscan, etc.).

    Sean> I believe that we need to distinguish between version numbers
    Sean> without Debian revisions and native source package formats.
    Sean> At one point an experienced contributor convinced me that
    Sean> there are cases where it is good to use a version number with
    Sean> a Debian revision but a native source package format.

I agree with this advice.
Does the current tooling support it?

    Sean> Perhaps we can already write something useful in Policy about
    Sean> packages which don't use Debian revisions, even though there
    Sean> is a lack of consensus about source package formats?
    Sean> Something like: you should always include a Debian revision
    Sean> unless the package has a release process which is tightly
    Sean> coupled with making uploads to the Debian archive (and we
    Sean> would not want to include the converse, that having such a
    Sean> tight coupling implies you shouldn't include a Debian
    Sean> revision).

Assuming that dpkg-source supports this, I would generally support the
advice you're working toward and would be likely to second specific
text.