On Mon, 27 Jun 2022 09:23:25 -0700 Sean Whitton <spwhit...@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.
