>>>>> "Sean" == Sean Whitton <spwhit...@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.
