Bug#1107137: Distinguish "native source packsge" from "native version number"

[Russ Allbery <rra@debian.org>]

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

> There is clearly consensus that source format 1.0 is deprecated.

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

> So the discussion in "past 10 years" you refer to already had a clear
> outcome.

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

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>