On 4 February 2014 18:15, Guillem Jover <guil...@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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
