XPost: linux.debian.bugs.dist
From: dimitri.ledkov@canonical.com

On Mon, 27 Jun 2022 09:23:25 -0700 Sean Whitton
<spwhitton@spwhitton.name> wrote:

With three first preference votes for A and five first preference votes
for C, the outcome is no longer in doubt. Therefore, using its powers
under constitution 6.1.5, the Technical Committee issues the following advice:

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.

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

3. We suggest that the wontfix tag on #737634 be reconsidered.

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.

5. We decline to comment on the recent source package format MBF.

Due to signing, many source packages produce template packages that
ideally track 1:1 matching version numbers. Specifically in Ubuntu,
this is used to generate 3.0 (native) linux-meta, linux-signed, linux-restricted-modules, linux-restricted-signattures containing
secureboot signed artifacts that are otherwise require to have 1:1
matching version with non-native src:linux. Similar is also true for s390-tools, grub, shim, fwupdate, etc.

With this bug remaining unfixed, it remains true that Debian version
of dpkg tooling is unable to process or recreate source packages as
shipped in Ubuntu (and its derivatives).

Alternatives of specifying 3.0 (quilt) and generating empty orig
tarball - is very ugly, as one has to upload tiny empty files. And is
error prone as it might not be possible to recreate those
reproducibly.

What can be done to move with this issue?

Or what other versioning scheme and format can one use here? As there
is a legitimate need to generate packages of a given version with
revision, without any orig tarballs. Can 3.0 (quilt) operate without
any orig tarballs?

Regards,

Dimitri.

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)