Bug#737634: dpkg: Allow overriding is_native version checks in dpkg 3.0 Native.

[Dimitri John Ledkov]

Package: dpkg
Version: 1.17.0
Severity: wishlist
Tags: patch

Dear Maintainer,

As part of 1.17.0 bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 was fixed, which
whilst enforcing Debian Policy, breaks backwards compatability for 3rd
party packages that (ab)use bad version numbers. In effort to preserve
backwards compatibility where such packages still need to be maintained
please allow override is_native version check in dpkg 3.0 Native format.

Patch attached.

Regards,

Dimitri.

[Guillem Jover]

Control: tag -1 wontfix

Hi!

On Tue, 2014-02-04 at 13:47:01 +0000, Dimitri John Ledkov wrote:
> Package: dpkg
> Version: 1.17.0
> Severity: wishlist
> Tags: patch

> As part of 1.17.0 bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 was fixed, which
> whilst enforcing Debian Policy, breaks backwards compatability for 3rd
> party packages that (ab)use bad version numbers. In effort to preserve
> backwards compatibility where such packages still need to be maintained
> please allow override is_native version check in dpkg 3.0 Native format.

Part of the definition of what's and what's not a native package is
the version scheme, and I've never considered that a Debian specific
thing specified by its policy. The fact that dpkg-source has been
sloppy in the past for format 1.0 does not mean newer formats should
not behave better in that respect, and when the change was done it
was “pretty early” as to not have any major impact, because the
current state had not been dregraded.

This change does not affect extraction in any way, so backward
compatibility is preserved. If a maintainer is going to rebuild the
_source_ package, that means they have changed it, at which point they
might as well fix the bogus version. There's also no connection
whatsoever between the source and binary versions, so you can still use
stuff like pkg-source_0 with pkg-binary1_2.0-1 and pkg-binary2_1:4.0-10
produced from the same source package, for example.

Given the above, I don't see any reason at all to support this, and
I'm thus marking this report as wontfix, and will be closing in a bit.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Dimitri John Ledkov]

On 4 February 2014 18:15, Guillem Jover <gui...@debian.org> wrote:
> Control: tag -1 wontfix
>
> Hi!
>
> On Tue, 2014-02-04 at 13:47:01 +0000, Dimitri John Ledkov wrote:
>> Package: dpkg
>> Version: 1.17.0
>> Severity: wishlist
>> Tags: patch
>
>> As part of 1.17.0 bug report
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 was fixed, which
>> whilst enforcing Debian Policy, breaks backwards compatability for 3rd
>> party packages that (ab)use bad version numbers. In effort to preserve
>> backwards compatibility where such packages still need to be maintained
>> please allow override is_native version check in dpkg 3.0 Native format.
>
> Part of the definition of what's and what's not a native package is
> the version scheme, and I've never considered that a Debian specific
> thing specified by its policy. The fact that dpkg-source has been



"""

Format: 3.0 (native)
This format is an extension of the native package format as defined in
the 1.0 format. It supports all compression methods and will ignore by
default any VCS specific files and directories as
well as many temporary files (see default value associated to
-I option in the --help output).
"""
"""
Format: 1.0
A source package in this format consists either of a .orig.tar.gz
associated to a .diff.gz or a single .tar.gz (in that case the package
is said to be native).
"""

By this definition, versioning scheme is not canonical declaration of
the source format and imposes no constraints on the package.

We have explicit ./debian/source/format and --format option to
declare, without guessing, the intended source format of the package.
Why do we have that file and command line option, if that's not the
canonical way to declare what's "1.0", "3.0 (quilt)" and what's "3.0
(native)".

> sloppy in the past for format 1.0 does not mean newer formats should
> not behave better in that respect, and when the change was done it
> was “pretty early” as to not have any major impact, because the
> current state had not been dregraded.
>

It was not "pretty early" it's been done way too late. It breaks
upgrade path from 1.0 format, and makes it impossible to use testing
to regenerate existing (abeit non-policy compliant) packages.

> This change does not affect extraction in any way, so backward
> compatibility is preserved. If a maintainer is going to rebuild the
> _source_ package, that means they have changed it, at which point they
> might as well fix the bogus version. There's also no connection

True, but I didn't receive an .orig.* tarball, therefore I also don't
have one. And as an NMU or Security / Stable update, it's not my right
right to change that or introduce an .orig.* tarball into the archive.

> whatsoever between the source and binary versions, so you can still use
> stuff like pkg-source_0 with pkg-binary1_2.0-1 and pkg-binary2_1:4.0-10
> produced from the same source package, for example.
>
> Given the above, I don't see any reason at all to support this, and
> I'm thus marking this report as wontfix, and will be closing in a bit.
>

I disagree with your resolution, and maintain the position, that it
should be possible to force dpkg-source to regenerate 3.0 (native)
packages with non-native version numbers as it was previously possible
for the 3.0 (native) format, same as it is possible using stable
release of dpkg in . There are multiple cases in Debian, and in
derivative distributions where such packages exists. It's not a large
pool of packages, but the compatibility for those has been broken with
no ways to revert it.

I want to refer this bug report to the technical committee for a
resolution. Would you agree to a following statement of technical
conflict:

"""
* dpkg-source supports multiple source package formats: 1.0, 3.0
(native), 3.0 (quilt) and others that are not in common use and/or not
accepted into the Debian archive.
* Up until 1.17.0 release, it was possible to generate 1.0 (single
tarball) and 3.0 (native) source packages regardless of the version
string used (be it with or without "-" component).
* When a version string has "-" component, and no original
tarball/direcotry is specified, dpkg-source displays a warning
messages and asks the user for confirmation to proceed.
* In 1.17.0, this behavior has been changed for 3.0 (native) packages,
such that dpkg-source bails and a source package is not build if a
version string appears to be non-native.
* Reporter of the bug 737634 believes this is a regression, whilst
package maintainer sees no reason at all to support building source
packages in such configurations.
* On the bug 737634, reporter proposed a patch for a 3.0 (native)
source package format specific dpkg-source flag/option which allows
the maintainer to override the dpkg-source version numbering check.
The bugreport has been marked as wontfix by maintainer.
"""

? If yes, i'll open tech-ctte bug report and block this bug with the
tech-ctte bug report.

--
Regards,

Dimitri.

[Dimitri John Ledkov]

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