Debian Bug report logs - #737634
dpkg: Allow overriding is_native version checks in dpkg 3.0 Native.

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Dimitri John Ledkov <xnox@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg: Allow overriding is_native version checks in dpkg 3.0 Native.

Date: Tue, 04 Feb 2014 13:47:01 +0000

[Message part 1 (text/plain, inline)]

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.

[0001-Add-force-native-dpkg-source-option-to-override-is_n.patch (text/x-diff, inline)]

From 29da323dccc5d3eaf76046c79f6513fcab5c2195 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Date: Tue, 4 Feb 2014 13:43:13 +0000
Subject: [PATCH] Add --force-native dpkg-source option to override is_native
 version check in "3.0 (Native)" format to preserve backwards compatibility
 for those that maintain packages which abused bad version numbers with dpkg
 << 1.17.0.

---
 debian/changelog                         |  6 ++++++
 scripts/Dpkg/Source/Package/V3/Native.pm | 20 +++++++++++++++++++-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 3128c68..f17ec42 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -12,6 +12,12 @@ dpkg (1.17.7) UNRELEASED; urgency=low
   * German (Helge Kreutzmann).
   * Swedish (Peter Krefting).
  
+  [ Dimitri John Ledkov ]
+  * Add --force-native dpkg-source option to override is_native version
+    check in "3.0 (Native)" format to preserve backwards compatibility for
+    those that maintain packages which abused bad version numbers with
+    dpkg << 1.17.0.
+
  -- Guillem Jover <guillem@debian.org>  Wed, 15 Jan 2014 19:02:55 +0100
 
 dpkg (1.17.6) unstable; urgency=low
diff --git a/scripts/Dpkg/Source/Package/V3/Native.pm b/scripts/Dpkg/Source/Package/V3/Native.pm
index 5b833e1..22760f6 100644
--- a/scripts/Dpkg/Source/Package/V3/Native.pm
+++ b/scripts/Dpkg/Source/Package/V3/Native.pm
@@ -37,6 +37,24 @@ use File::Temp qw(tempfile);
 
 our $CURRENT_MINOR_VERSION = '0';
 
+sub init_options {
+    my ($self) = @_;
+    $self->{options}{force_native} = 0
+        unless exists $self->{options}{force_native};
+
+    $self->SUPER::init_options();
+}
+
+sub parse_cmdline_option {
+    my ($self, $opt) = @_;
+    return 1 if $self->SUPER::parse_cmdline_option($opt);
+    if ($opt =~ /^--force-native$/) {
+        $self->{options}{force_native} = 1;
+        return 1;
+    }
+    return 0;
+}
+
 sub do_extract {
     my ($self, $newdirectory) = @_;
     my $sourcestyle = $self->{options}{sourcestyle};
@@ -70,7 +88,7 @@ sub can_build {
 
     my $v = Dpkg::Version->new($self->{fields}->{'Version'});
     return (0, _g('native package version may not have a revision'))
-        unless $v->is_native();
+        unless ($v->is_native() or $self->{options}{force_native});
 
     return 1;
 }
-- 
1.9.rc1

Message #10 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>

To: "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>, 737634@bugs.debian.org

Subject: Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Tue, 4 Feb 2014 14:05:45 +0000

On 4 February 2014 13:38, Jakub Wilk <jwilk@debian.org> wrote:
> * Dimitri John Ledkov <xnox@debian.org>, 2014-02-04, 13:30:
>
>> Enforcing Debian Policy at dpkg-source -b . level, is not a good idea,
>> especially when it breaks backwards compat for 3rd parties. We have lintian,
>> and ftp-master lintian auto-rejects to clense the archive if so is desired.
>
>
> Hear, hear. And I even doubt there's consensus it is desired.
>

Patch is attached to the new bug filed about this issue
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634
Proposed patch adds "--force-native" dpkg-source option for the "3.0
(Native)" format, which ignores enforcing native version number check.

-- 
Regards,

Dimitri.

Message #15 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>

Cc: "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>, 737634@bugs.debian.org

Subject: Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Tue, 4 Feb 2014 14:30:46 +0000

Dimitri John Ledkov writes ("Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages"):
> Patch is attached to the new bug filed about this issue
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737634
> Proposed patch adds "--force-native" dpkg-source option for the "3.0
> (Native)" format, which ignores enforcing native version number check.

Thanks for that.  (Sorry, please ignore my previous mail.)

I think that this behaviour needs to be the default.  Otherwise there
are packages in the archive that cannot be processed with the new
tool using the default options, which I think is a
non-backwards-compatible change.

Ian.

Message #20 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Dimitri John Ledkov <xnox@debian.org>, 737634@bugs.debian.org

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

Date: Tue, 4 Feb 2014 19:15:30 +0100

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

Message #27 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Charles Plessy <plessy@debian.org>

Cc: debian-devel@lists.debian.org, 737634@bugs.debian.org

Subject: Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 05 Feb 2014 04:57:36 -0500

control: subscribe -1


>>>>> "Charles" == Charles Plessy <plessy@debian.org> writes:


    Charles> The 3.0 (native) format is useful when packaging a work
    Charles> that is developped and distributed in a Git repository.
    Charles> Please leave us this possibility.

Let me describe the use case I have which is an expansion on the above.
I have a bunch of software that I perform daily builds for  out of
version control (git in my case but the issue applies to other vcs as
well).
The software does have upstream versions but is not stable enough that
upstream release tarballs are useful to anyone.
Honestly at this point, I'm not sure anyone will ever find upstream
tarballs useful; anyone who is likely to want to build this from source
probably has a copy of git and can checkout a tag.

There is a packaging branch and an upstream branch.
Changes made on the packaging branch increment the debian revision;
changes made on the  ustream branch eventually involve an increment to
the upstream version.

Things get dumped into a Debian reprepro repository, and into Ubuntu
PPAs.
Eventually, things will get stable enough that I'll upload to a PPA.

Prior to that, I need a way to build a Debian package including source
from a directory without an upstream tar ball.  3.0(git) is not a
reasonable option because archive management programs have very little
support for it, and because package download tools probably aren't well
tested with it.

I'm happy to entertain other options rather than 3.0(native) but my
requirements are:

* support for upstream version
* support for debian revision

* No need to have upstream sources available to dpkg-buildpackage prior
  to running it

* No need to maintain .orig.tar.gz artifacts  produced by dpkg-source
  and keep the checksums of these artifacts consistent between packages
  with the same upstream versions.

Message #32 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Dimitri John Ledkov <xnox@debian.org>

To: Guillem Jover <guillem@debian.org>

Cc: 737634@bugs.debian.org

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

Date: Wed, 5 Feb 2014 10:43:21 +0000

On 4 February 2014 18:15, Guillem Jover <guillem@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.

Message #37 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Andreas Beckmann <anbe@debian.org>

Cc: debian-devel@lists.debian.org, 737634@bugs.debian.org

Subject: Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 05 Feb 2014 12:46:09 +0100

On 2014-02-05 10:57, Sam Hartman wrote:
> tarballs useful; anyone who is likely to want to build this from source
> probably has a copy of git and can checkout a tag.

Such a tag corresponds to an upstrema version?

> I'm happy to entertain other options rather than 3.0(native) but my
> requirements are:
> 
> * support for upstream version
> * support for debian revision
> 
> * No need to have upstream sources available to dpkg-buildpackage prior
>   to running it
> 
> * No need to maintain .orig.tar.gz artifacts  produced by dpkg-source
>   and keep the checksums of these artifacts consistent between packages
>   with the same upstream versions.

All this sounds like it can be done with git-buildpackage
--git-pristine-tar --git-pristine-tar-commit. Can be set in
debian/gbp.conf. And maybe dpkg-source --single-debian-patch.
And if this doesn't work for you, we should enhance the tools e.g.
git-buildpackage, to better support the desired workflows (i.e. what you
really want to achieve), not the workarounds (the way you used achieve
this today^Wyesterday^Wbefore dpkg 1.17).

And your goal seems to be: "I have a git repository with upstream
branch, tags, debian branch and I want an easy solution (command) to
build conforming packages without having to worry about details like
creating upstream tarballs." and not "I need to upload foo 1.2-3 with
source format 3.0 (native)".

Andreas

Message #42 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Andreas Beckmann <anbe@debian.org>

Cc: 737634@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 05 Feb 2014 07:21:27 -0500

>>>>> "Andreas" == Andreas Beckmann <anbe@debian.org> writes:

    Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
    >> tarballs useful; anyone who is likely to want to build this from
    >> source probably has a copy of git and can checkout a tag.

    Andreas> Such a tag corresponds to an upstrema version?

yes.

    >> I'm happy to entertain other options rather than 3.0(native) but
    >> my requirements are:
    >> 
    >> * support for upstream version * support for debian revision
    >> 
    >> * No need to have upstream sources available to dpkg-buildpackage
    >> prior to running it
    >> 
    >> * No need to maintain .orig.tar.gz artifacts produced by
    >> dpkg-source and keep the checksums of these artifacts consistent
    >> between packages with the same upstream versions.

    Andreas> All this sounds like it can be done with git-buildpackage
    Andreas> --git-pristine-tar --git-pristine-tar-commit. Can be set in
    Andreas> debian/gbp.conf. And maybe dpkg-source
    Andreas> --single-debian-patch.  

no, that means I have to maintain the artifact (namely the
.orig.tar.gz).
The archive software (both reprepro and dak were I to use that) require
that the .orig.tar.gz not change checksums.

I don't want my build machines to be able to push back to my master
repository.
Nor do I want to have to release upstream versions if I lose state on my
build machines.
So this violates my requirements because I have to maintain  an artifact
of dpkg-source (the .orig.tar.gz) and makesure its checksum never
changes.

Also, using git-buildpackage is difficult.
The build is done by sbuild, which does not call git-buildpackage.

Message #47 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: 737634@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 5 Feb 2014 12:59:23 +0000

[Message part 1 (text/plain, inline)]

On Wed, 5 Feb 2014 12:21:30 +0000
Sam Hartman <hartmans@debian.org> wrote:

> >>>>> "Andreas" == Andreas Beckmann <anbe@debian.org> writes:
> 
>     Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
>     >> tarballs useful; anyone who is likely to want to build this
>     >> from source probably has a copy of git and can checkout a tag.
> 
>     Andreas> Such a tag corresponds to an upstrema version?
> 
> yes.
> 
>     >> I'm happy to entertain other options rather than 3.0(native)
>     >> but my requirements are:
>     >> 
>     >> * support for upstream version * support for debian revision
>     >> 
>     >> * No need to have upstream sources available to
>     >> dpkg-buildpackage prior to running it
>     >> 
>     >> * No need to maintain .orig.tar.gz artifacts produced by
>     >> dpkg-source and keep the checksums of these artifacts
>     >> consistent between packages with the same upstream versions.
> 
>     Andreas> All this sounds like it can be done with git-buildpackage
>     Andreas> --git-pristine-tar --git-pristine-tar-commit. Can be set
>     Andreas> in debian/gbp.conf. And maybe dpkg-source
>     Andreas> --single-debian-patch.  
> 
> no, that means I have to maintain the artifact (namely the
> .orig.tar.gz).
> The archive software (both reprepro and dak were I to use that)
> require that the .orig.tar.gz not change checksums.

Using packages to support upstream development is a common problem and
this is exactly where things get awkward.

For my own role within an upstream team, I'm considering using
"unofficial" or "developer" upstream tarball releases. We'll probably
use a date based tag 2014.02 etc for the main monthly release.
Developer builds will have a shortened git hash appended (this happens
to match our existing deployment method) like 2014.02.234fdga2 and
incremental upstream releases will use tag.01 etc. so 2014.02.01

This has advantages that developers self-verify that the tarballs work
which finds problems due to new files not being included in the
tarball. It also retains the upstream packaging behaviour.

> I don't want my build machines to be able to push back to my master
> repository.
> Nor do I want to have to release upstream versions if I lose state on
> my build machines.
> So this violates my requirements because I have to maintain  an
> artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum
> never changes.
> 
> Also, using git-buildpackage is difficult.
> The build is done by sbuild, which does not call git-buildpackage.

Not true. There are options to use debuild or pdebuild or
dpkg-buildpackage in-place.

e.g. I use:

[DEFAULT]
#builder = git-pbuilder
builder = debuild
cleaner = fakeroot debian/rules clean
pristine-tar = True

[git-buildpackage]
export-dir = ../build-area/
tarball-dir = ../tarballs/

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[signature.asc (application/pgp-signature, attachment)]

Message #52 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: debian-devel@lists.debian.org, 737634@bugs.debian.org

Subject: Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 5 Feb 2014 22:17:35 +0900

Le Wed, Feb 05, 2014 at 12:46:09PM +0100, Andreas Beckmann a écrit :
> 
> All this sounds like it can be done with git-buildpackage

Hello everybody,

I have the impression that we are arguing because of solution in search for a
problem.

Some things worked with the previous version of dpkg, with no extra work for
anybody.

Who benefited directly from the change of behavior ?  Nobody ?  Then please
revert it; it was not necessary.

I propose a compromise.

 - First, somebody convinces Joey to switch the ikiwiki to a non-native
   format.  If you can twist the arm of a highly reputed developer, it means
   that the problem that you attempted to solve (a stricter distinction between
   native and non-native packages) was really important.

 - Then, we consider that others can follow.

 - In the meantime, please revert the change in dpkg.  There is no need to
   prevent packages in the 3.0 (native) format to use non-native version
   number.

Alternatively, please rename the "3.0 (native)" format to "3.0 (tarball)" or
anything elese, and we are done.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #57 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: 737634@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: dpkg: is_native version checks in dpkg 3.0 Native

Date: Wed, 5 Feb 2014 13:54:17 +0000

Guillem writes, on the bug but not on debian-devel:
> 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.

(I reproduce the whole message so that -devel can see it.)

Guillem, please reconsider.

Firstly, as people have illustrated, there are situations where a
native format package with a Debian revision is a useful thing to
have.

Secondly, there doesn't appear to be any support in policy for this
restriction.

Thirdly, notwithstanding your comments, I think this change is a
problem for backwards-compatibility.  People modifying source packages
might be doing so in a context where they don't want to, or can't
conveniently, change the version number of the source format.  They
might also be using dpkg-source to prepare packages for a downstream
distro who don't have the same fixed opinion about the versions.

Can you please explain what you think the concrete benefit is of this
change ?  At the moment we have numerous packages in this state and
they don't cause any problems.

As you can see from debian-devel, there is a clear consensus that this
change should be reverted.

Thanks,
Ian.

Message #62 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: Neil Williams <codehelp@debian.org>

Cc: 737634@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 05 Feb 2014 08:58:12 -0500

>>>>> "Neil" == Neil Williams <codehelp@debian.org> writes:


That makes sense and I do something similar as appropriate.  Even so, I
do not wish to maintain the upstream tarball as a maintained artifact.
There are cases where packaging release releases are made.  Maintaining
pristine-tar commits for daily builds is a worse solution than
3.0(native) or not including source packages in the resulting Debian
archive.

Message #67 received at 737634@bugs.debian.org (full text, mbox, reply):

From: "Bernhard R. Link" <brlink@debian.org>

To: debian-devel@lists.debian.org

Cc: 737634@bugs.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 5 Feb 2014 18:14:20 +0100

* Sam Hartman <hartmans@debian.org> [140205 13:27]:
> no, that means I have to maintain the artifact (namely the
> .orig.tar.gz).
> The archive software (both reprepro and dak were I to use that) require
> that the .orig.tar.gz not change checksums.
> 
> I don't want my build machines to be able to push back to my master
> repository.
> Nor do I want to have to release upstream versions if I lose state on my
> build machines.
> So this violates my requirements because I have to maintain  an artifact
> of dpkg-source (the .orig.tar.gz) and makesure its checksum never
> changes.

This answers the question why you want to use a 3.0 (native) package.
But the real question here is: Why do you want to use a version with "-"
for such a package?

	Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Message #72 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Sam Hartman <hartmans@debian.org>

To: debian-devel@lists.debian.org

Cc: 737634@bugs.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Wed, 05 Feb 2014 13:21:56 -0500

>>>>> "Bernhard" == Bernhard R Link <brlink@debian.org> writes:


As I mentioned I have a packaging branch and an upstream branch.
I wish to use debian revisions to reflect packaging changes.

It's slightly more complex than changes to debian directory involve a
debian revision change; changes to other things involve a upstream
version change.

As an example I produce both RPMs and Debs. Just as I don't want to
increment the upstream version number because of a spec file change, I
don't want to increment the upstream version number because I updtaded
build-depends in debian/control.
Especially when the debian directory isn't even on the upstream master
branch.  Incrementing the upstream version number (which appears in
configure.ac among other places) so I could make changes to files that
don't even appear on that branch is an undesirable work flow.

I guess I could have a debian upstream version number that differed from
the actual upstream version number.
That seems undesirable from a user expectations standpoint as well as
potentially impacting things in unexpected ways.

The bug claims that it is a violation of policy to  use 3.0(native)
without  a.orig.tar.something.
I'm actually failing to find that in policy at all.
I'm finding some SHOULD level recommendations, but certainly not MUST
level recommendations, I can think of reasons why a maintainer might
want to voiolate those shoulds.

Message #77 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 737634@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native

Date: Wed, 5 Feb 2014 21:08:04 +0100

Hi!

On Wed, 2014-02-05 at 13:54:17 +0000, Ian Jackson wrote:
> Guillem writes, on the bug but not on debian-devel:
> > 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.

> Guillem, please reconsider.

Sorry, I should have added here my usual note about being open to
reconsideration *if* convincing arguments are put forward. But I
was pretty much unimpressed with the way this had been brought up.
Way more so now with the threats of TC force, but I guess that's
the new Debian-way…

> Firstly, as people have illustrated, there are situations where a
> native format package with a Debian revision is a useful thing to
> have.

What I get from that thread and previous ones is that our tools might
be suboptimal, simply suck or might make things difficult when it
comes to some specific workflows. In my book the way to fix that is to
improve the tools, create new ones or new formats, not to workaround
and shoehorn stuff into them (at least for the new formats, the old
one is incurable at this point).

> Secondly, there doesn't appear to be any support in policy for this
> restriction.

§3.2.1

  “If punctuation is desired between the date components, remember
   that hyphen (`-') cannot be used in native package versions.”

§5.6.12

  <upstream_version>
  “If there is no <debian_revision> then hyphens are not allowed;”

  <debian_revision>
  “This part of the version number specifies the version of the
   Debian package based on the upstream version.”
  …
  “It is optional; if it isn't present then the <upstream_version>
   may not contain a hyphen.  This format represents the case where
   a piece of software was written specifically to be a Debian
   package, where the Debian package source must always be identical
   to the pristine source and therefore no revision indication is
   required.”

> Thirdly, notwithstanding your comments, I think this change is a
> problem for backwards-compatibility.  People modifying source packages
> might be doing so in a context where they don't want to, or can't
> conveniently, change the version number of the source format. They
> might also be using dpkg-source to prepare packages for a downstream
> distro who don't have the same fixed opinion about the versions.

If people are preparing stable updates, I'd expect them to do that in
a stable system, no problem here. If people are updating ancient
source packages in a modern system they will need to change way more
things anyway (due to compilers, deprecated stuff, etc). If people
are updating someone else's package (say an NMU) for a bogus native
package, they have to create an entire new source package with new
upstream tarball(s) anyway, switching the source format is a very
tiny change in comparison, and this type of change is pretty common
when transitions or unrelated FTBFS bugs are involved. If the context
is completely outside of Debian, and neither the source version nor
the source format can/wants to be changed (?), that _might_ call at
most for a force option allowing bogus versions, but certainly not
for a revert. But please, see below for how big of a problem this
currently is in Debian.

And this is a bit of a tangent, but IMO changing the source format
(from native to non-native) is the correct thing to do anyway for
native packages when modified by someone else than the author,
because I find it's pretty inappropriate to release a new upstream
release on behalf of the upstream author, taking over the version
namespace and file release namespace when those changes might not
even survive, which can be confusing towards downstreams in other
distributions who might not be aware of these nuances, or those
changes might be part of a derivative, in which case taking over
those namespaces would be inappropriate too.

> Can you please explain what you think the concrete benefit is of this
> change ?

Our source packages are already pretty complicated, mixing native
packages with non-native versions (and the reverse which is even worse)
adds to the confusion, for current and new packagers, and external
people to the project (we'd have what, true-native packages,
half-native, non-native, non-native-haha-version, etc?). The
distinction in source version 1.0 was pretty flaky, as it was defined
by the presence of specific filenames. With newer source versions this
is made explicit, if then the version scheme does not match, it makes
it even worse.

Disallowing bogus versions from the root (that is dpkg), makes for
better packages in our ecosystem, even for people that do not know or
cannot be bothered to know about these distinctions. It also reduces
having to handle strange corner cases in support tools (as Bernhard
has pointed out).

Usage of native format packages (any version) for non-native upstreams
implies that for each packaging revision there's a new source tarball,
this might be passable for the 47-odd packages doing so currently
(althought some of those should be true-native), it certainly does not
scale at all in the future if applied to the whole archive (even less
so if those packages start also shipping stuff like the entire .git/
directory), regardless of the usual “disks are cheap” mantra.

It's also a disservice towards derivatives and other people using
these source packages as a base, as the changes are not clearly
separated and visible. If people think juggling source tarballs
around is antiquated and a nuisance, and the only true form of
distribution should be the DVCS-of-choice, then let's drop these
source formats, but let's not abuse them for something they are
not designed for.

My impression is that most of the cases in
<http://lintian.debian.org/tags/non-native-package-with-native-version.html>
and
<http://lintian.debian.org/tags/native-package-with-dash-version.html>
are due to either mistakes/sloppiness, not knowing things like that
date-based versions (such as 2010-09) are problematic for native
packages, ignoring the fact that source version and binary version
do not have to match at all as long as they increment monotonically
(like the default package cases), or abusing the current formats for
a different workflow.

The last two options seem to be the only ones done on purpose, the
former is a matter of using a correct native source version distinct
from the binary package ones. The latter might be a matter of
improving our tools or similar to support such workflows.

> At the moment we have numerous packages in this state and
> they don't cause any problems.

We have exactly three (3) packages in unstable that are in this
state, namely: davical, pimd, tk-brief. We had 9 when this change got
introduced, and none for the «3.0 (quilt)» with native version.

> As you can see from debian-devel, there is a clear consensus that this
> change should be reverted.

Sorry, but I don't see a clear consensus there. I see some people that
say this should be reverted, some that say the proposed usages are
bogus anyway, and then some confused messages about what this affects
or not. For example, what does ikiwiki (a native package with a native
version) has to do with anything?


(And a preposterous proposal, I guess I should be changing also
Dpkg::Version->is_native() to return "maybe"? :)


Thanks,
Guillem

Message #82 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Dimitri John Ledkov <xnox@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 737634@bugs.debian.org, "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>

Subject: Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native

Date: Thu, 6 Feb 2014 01:05:20 +0000

On 5 February 2014 20:08, Guillem Jover <guillem@debian.org> wrote:
> Hi!
>
> On Wed, 2014-02-05 at 13:54:17 +0000, Ian Jackson wrote:
>> Guillem writes, on the bug but not on debian-devel:
>> > 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.
>
>> Guillem, please reconsider.
>
> Sorry, I should have added here my usual note about being open to
> reconsideration *if* convincing arguments are put forward. But I
> was pretty much unimpressed with the way this had been brought up.
> Way more so now with the threats of TC force, but I guess that's
> the new Debian-way…

?!

If you interpreted any of my emails as threats, I'm deeply sorry and
in no way, I meant it this way.

>
>> Firstly, as people have illustrated, there are situations where a
>> native format package with a Debian revision is a useful thing to
>> have.
>
> What I get from that thread and previous ones is that our tools might
> be suboptimal, simply suck or might make things difficult when it
> comes to some specific workflows. In my book the way to fix that is to
> improve the tools, create new ones or new formats, not to workaround
> and shoehorn stuff into them (at least for the new formats, the old
> one is incurable at this point).
>
>> Secondly, there doesn't appear to be any support in policy for this
>> restriction.
>
> §3.2.1
>
>   “If punctuation is desired between the date components, remember
>    that hyphen (`-') cannot be used in native package versions.”
>
> §5.6.12
>
>   <upstream_version>
>   “If there is no <debian_revision> then hyphens are not allowed;”
>
>   <debian_revision>
>   “This part of the version number specifies the version of the
>    Debian package based on the upstream version.”
>   …
>   “It is optional; if it isn't present then the <upstream_version>
>    may not contain a hyphen.  This format represents the case where
>    a piece of software was written specifically to be a Debian
>    package, where the Debian package source must always be identical
>    to the pristine source and therefore no revision indication is
>    required.”
>

This is how Debian Policy defines version numbers for the Debian
Project and the Debian Archive.
This is not always the case for derivatives, ISV developers, or others
using dpkg toolchain.
My particular use case falls outside of Debian Archive / Debian Policy.
Thus i'm asking to consider backwards compatibility, in a wider context.

I agree that for Debian Archive and Debian Policy it is probably the
right enforcmement. It's on a far lower level, than I'd expect it to
be.
Hence I did not propose the revert, and only proposed an optional
feature flag to enable this quirky behaviour to allow, specifically,
build a 3.0 (native) package with a non-native version number.

<snip all the claims, which are not those that i raised and citations
of debian policy which do not apply, in the context outside of Debian
Developers targetting things for the Debian Archive proper>

>> As you can see from debian-devel, there is a clear consensus that this
>> change should be reverted.
>
> Sorry, but I don't see a clear consensus there. I see some people that
> say this should be reverted, some that say the proposed usages are
> bogus anyway, and then some confused messages about what this affects
> or not. For example, what does ikiwiki (a native package with a native
> version) has to do with anything?
>
>

Can we all please back track a bit.

A particular use-case I have is that, at times, there is a need to
build a stand-alone src+binary packages with a strict one-to-one
mapping to the src+debs already in the official archive.
Especially when this strict matching source package, actually contains
non-reproducible / non-free / prebuild binaries exactly against the
free matching src+debs in the official archive.

e.g. linux 3.13.0-6 source package, which is uploaded into the
archive, built on the autobuilders.
Later it is fetched, taken offline for secure-boot signing, the
detached signatures stripped and assembled into a linux-signed
3.13.0-6 source package which only contains the detached signatures.
At build-time of linux-signed package, it can then depend on stricly
self-package version string to reattach secure-boot signature in the
archive or similarly assembly singed kernel image on the client
machine.
In a similar fashion, i expect ISV vendors to potentially ship
prebuild binaries/plugins/extension/etc in the version string matching
source+deb packages in the official archives.

1.0 is a capable format that allows for this, similarly 3.0 (native)
is a better one (default VCS ignore + better compression algorithms)
to support this typo of atypical interaction.
The 3.0 (native) is no longer possible to be build with a version
string which "is_native() == true" after the fix for bug #700177
landed in 1.17.0.

I agree that bug #700177 is valid, and Debian should not by default
allow such misformated packages to be generated. Further I agree with
Guilliem that there is no requirement, nor wide-spread use for such
miss-combination (on Debian Policy terms) in the Debian Archive. And
our tools should not do stupid things, or allow for stupid things to
happen. E.g. like the systemd 204 upload which even with all the git-*
package helper-foo and pristine-tar intentions got uploaded into the
Debian Archive with an auto-generated tarball by dpkg-source. Such
sloppiness is something that dpkg-source is ought to catch, and
hard-fail the source package assembly. Therefore I fully agree with
Guilliem's reasoning here.

However, the use case of intentional matching version string to the
other src+bin package from a third-party/non-free or due to signing,
is in my opinion useful to those who use dpkg-source for something
else then "package yet another package for the Debian Archive" and
exactly to give control as to what is intentionally generated I
proposed an "opt-out of hard-failure" flag --force-native to support
building "3.0 (native) package with a non-native version string". I
did not propose a matching flag to allow building "3.0 (quilt) package
with a native version string" as i think it's silly and is much better
support by e.g. "dh --with quilt" inside the native package. From a
purity stand-point, we should be able to support patch queue per
tarball (be it native, upstream, or tarball component in multi-tarball
setup) in practice only a handful of packages reasonably need such
complexities (e.g. the well-cited glibc, gcc and etc patching
machineries).

I believe that adding "--force-native" option flag is the universally
minimal maintenance cost to support above use-case, and is on the
border-line sane as at least it establishes a clear "version-string"
based audit trail.

My other option is to revert those set of packages to use 1.0 with
worse compression rates, and "monkey-patch" / copy&paste 3.0 based
ignore patterns to prevent accidental inclusion of VCS files. That
would, i hope, preserve buildability of those packages with any
dpkg-source. But that is increased maintainance cost, and worse
performance / developer expectations - as majority of packages these
days are capable of 3.0 compression algorithms and most people are
used to the default ignore patters of the 3.0 based formats.

I'm unconvinced about "daily snapshots" etc. arguments, as they will
break if you happen to have a stale .orig.tar or dir or unclean build.
You still need to manually track and increment the version number e.g.
20140206.1, 20140206.2 etc. And no, you can't just suffix a git commit
id as those are not linearly incremental within a given day. Also i've
seen similar silliness where commits were merged from the past, with
old dates, and thus "new" src and binary packages got uploaded with a
datebased version number months older than previous upload.

-- 
Regards,

Dimitri.

Message #87 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Neil Williams <codehelp@debian.org>

Cc: 737634@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Mon, 10 Feb 2014 22:13:45 +0100

Sigh.

On Wed, Feb 05, 2014 at 12:59:23PM +0000, Neil Williams wrote:
> Using packages to support upstream development is a common problem and
> this is exactly where things get awkward.

No, it is not a *problem*; it is a *method* of doing things.

It is not your place (nor mine) to question another person's methods of
doing things; especially not if said methods are done outside of Debian,
as is here the case.

Enforcing Debian Policy in the tools (i.e., not allowing to do things
contrary to debian policy, even if that's wanted) is a *bad* idea, in
all cases.

[...]
> > Also, using git-buildpackage is difficult.
> > The build is done by sbuild, which does not call git-buildpackage.
> 
> Not true. There are options to use debuild or pdebuild or
> dpkg-buildpackage in-place.
> 
> e.g. I use:
> 
> [DEFAULT]
> #builder = git-pbuilder
> builder = debuild
> cleaner = fakeroot debian/rules clean
> pristine-tar = True
> 
> [git-buildpackage]
> export-dir = ../build-area/
> tarball-dir = ../tarballs/

Even if so, this increases the complexity of the system, and requires
people to learn yet another tool to Just Do what was previously possible
with no extra fluff.

It's okay for a tool (like dpkg) to warn if something doesn't look
right. It's not okay for a tool (like dpkg) to pretend to be smarter
than the person operating said tool.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/

Message #92 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: Wouter Verhelst <wouter@debian.org>

Cc: 737634@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

Date: Tue, 11 Feb 2014 09:05:27 +0000

[Message part 1 (text/plain, inline)]

On Mon, 10 Feb 2014 22:13:45 +0100
Wouter Verhelst <wouter@debian.org> wrote:

> Sigh.
> 
> On Wed, Feb 05, 2014 at 12:59:23PM +0000, Neil Williams wrote:
> > Using packages to support upstream development is a common problem

/common problem/common source of problems/

> > and this is exactly where things get awkward.
> 
> No, it is not a *problem*; it is a *method* of doing things.

... one which I've used consistently for more years than I've been a DD
and had frequent problems with various assumptions in various tools
and in more distributions than just Debian and its derivatives.

Hopefully the clarification will show that I'm not questioning
the methods of anyone (other than possibly my own).

> It is not your place (nor mine) to question another person's methods
> of doing things; especially not if said methods are done outside of
> Debian, as is here the case.

... and in my ongoing work.

If using distribution tools for upstream development was easy, we might
not have had people developing tools like pypi, ruby gems, CPAN or a
whole range of other non-distribution distributive tools. This isn't
just a Debian problem. (Indeed fixing it in Debian isn't going to fix
the problems because upstreams will rarely fixate on a single
distribution across the entire team - for entirely sane reasons.)

It is right for upstream to want to deploy to FHS compliant paths and
use dependencies from the main distribution system etc. None of the
distribution tools for any of the distributions actually make it easy
to then develop within those paths without either rebuilding unreleased
upstream packages or copying files into privileged paths. Both of these
routes need sudo access which just makes things harder again. Why must
every developer have sudo access on the development box? That is
exactly why pypi and buildout have got so much traction. It annoys me
that I have to use such methods for upstream work because dpkg-dev is
too constrained by rules which *only* relate to "official" builds.

Doing a quick native build of a non-native package for use and
distribution within a known team is a *common requirement* for upstream
teams. (e.g. it means that developers can push to a branch, get a quick
native package built, uploaded locally, installed via an inotify and
available to test without the unnecessary step of building
an .orig.tar.gz in the middle.) It's not quite as clean or DRY as
restarting a daemon directly from a user-privilege git clone but it is
workable.

Why should that require two branches of the packaging files?

Developing using Debian is not just about development of Debian.
Upstream teams use dpkg-dev too.

Constraints which are entirely warranted for developing packages
destined for ftp-master are directly harmful for developing packages
destined for a repository on 192.168.

Yes this could work with overrides but those overrides need to be build
specific (not package specific or version specific). This is exactly
why a ~/.gbp.conf is the right approach.

> > Not true. There are options to use debuild or pdebuild or
> > dpkg-buildpackage in-place.
> > 
> > e.g. I use:
> > 
> > [DEFAULT]
> > #builder = git-pbuilder
> > builder = debuild
> > cleaner = fakeroot debian/rules clean
> > pristine-tar = True
> > 
> > [git-buildpackage]
> > export-dir = ../build-area/
> > tarball-dir = ../tarballs/
> 
> Even if so, this increases the complexity of the system, and requires
> people to learn yet another tool to Just Do what was previously
> possible with no extra fluff.
> 
> It's okay for a tool (like dpkg) to warn if something doesn't look
> right. It's not okay for a tool (like dpkg) to pretend to be smarter
> than the person operating said tool.

True - however, there will always be a need for tools like git-bp and
it is common to use aliases and JDTRT scripts to provide a consistent
interface no matter what changes beneath. Thankfully, none of those
hacks make it into Debian but that does mean that people within Debian
don't get to see how the tools are actually used.

Switching a non-native package to native arbitrarily is a necessary use
of dpkg and it needs to be supported cleanly and in a way which is easy
to override using a per-build configuration option.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[signature.asc (application/pgp-signature, attachment)]

Message #97 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 737634@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native

Date: Tue, 11 Feb 2014 18:39:47 +0900

Le Wed, Feb 05, 2014 at 09:08:04PM +0100, Guillem Jover a écrit :
> 
> Sorry, I should have added here my usual note about being open to
> reconsideration *if* convincing arguments are put forward. But I
> was pretty much unimpressed with the way this had been brought up.
> Way more so now with the threats of TC force, but I guess that's
> the new Debian-way…

Hi Guillem,

I would like you to consider that, what you would feel if the TC would push a
decision on you, we feel it when you push your decision on us.

Clearly, when my work was first interrupted by dpkg-dev after upgrading it, and
when I realised through the changelog and the bug log that it was an
unconcerted top-down decision, my feeling was that the contribution that I was
making was not as welcome as I thought, and that I should find a better way to
spend my time.

> For example, what does ikiwiki (a native package with a native
> version) has to do with anything?

The Ikiwiki package, which uses a native version number for a clearly
non-native work in the sense of Policy's section 3.2.1 ("packages which have
been written especially for Debian"), shows how inconsistent is the concept of
a "native" package.  It shows that there is no problem with the version number
indicating one thing and the source format indicating another one.  So please
revert your change, which solves no practical problems.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #102 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Adam Conrad <adconrad@debian.org>

To: 737634@bugs.debian.org

Subject: Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native

Date: Thu, 13 Feb 2014 14:02:27 -0700

FWIW, while this is hashed out on the Debian side as to whether to
revert the change, or allow an override flag, or whatever, this is
what I've applied in Ubuntu to allow us to get on with life.  This
seems to me like a reasonable solution for now.  I realize most
people don't read warnings from dpkg-buildpackage but, on the other
hand, I also don't think people need to be halted in their workflow
due to a strict adherence to Debian policy in dpkg.

(As an aside, I do tend to consider our use-cases that allow mixed
version/format a bug, but some of them are a bit hard to solve, like
telling people doing automagic recipe builds that they now need to
have pristine-tar info in their branches when they didn't before.)

diff -Nru dpkg-1.17.5ubuntu2/debian/changelog dpkg-1.17.5ubuntu3/debian/changelog
--- dpkg-1.17.5ubuntu2/debian/changelog	2014-01-17 18:02:57.000000000 +0000
+++ dpkg-1.17.5ubuntu3/debian/changelog	2014-02-05 14:28:34.000000000 +0000
@@ -1,3 +1,10 @@
+dpkg (1.17.5ubuntu3) trusty; urgency=medium
+
+  * Change native source version/format mismatch errors into warnings until
+    the dust settles on Debian bug 737634 about revert or override options.
+
+ -- Adam Conrad <adconrad@ubuntu.com>  Wed, 05 Feb 2014 07:26:29 -0700
+
 dpkg (1.17.5ubuntu2) trusty; urgency=medium
 
   * Backport patch from 1.17.6 to fix file descriptor leaks (LP: #1270132)
diff -Nru dpkg-1.17.5ubuntu2/scripts/Dpkg/Source/Package/V3/Native.pm dpkg-1.17.5ubuntu3/scripts/Dpkg/Source/Package/V3/Native.pm
--- dpkg-1.17.5ubuntu2/scripts/Dpkg/Source/Package/V3/Native.pm	2013-12-10 06:14:22.000000000 +0000
+++ dpkg-1.17.5ubuntu3/scripts/Dpkg/Source/Package/V3/Native.pm	2014-02-05 14:26:25.000000000 +0000
@@ -69,7 +69,7 @@
     my ($self, $dir) = @_;
 
     my $v = Dpkg::Version->new($self->{fields}->{'Version'});
-    return (0, _g('native package version may not have a revision'))
+    warning (_g('native package version may not have a revision'))
         unless $v->is_native();
 
     return 1;
diff -Nru dpkg-1.17.5ubuntu2/scripts/Dpkg/Source/Package/V3/Quilt.pm dpkg-1.17.5ubuntu3/scripts/Dpkg/Source/Package/V3/Quilt.pm
--- dpkg-1.17.5ubuntu2/scripts/Dpkg/Source/Package/V3/Quilt.pm	2013-12-10 06:14:22.000000000 +0000
+++ dpkg-1.17.5ubuntu3/scripts/Dpkg/Source/Package/V3/Quilt.pm	2014-02-05 14:26:17.000000000 +0000
@@ -76,7 +76,7 @@
     return ($code, $msg) if $code == 0;
 
     my $v = Dpkg::Version->new($self->{fields}->{'Version'});
-    return (0, _g('version does not contain a revision')) if $v->is_native();
+    warning (_g('version does not contain a revision')) if $v->is_native();
 
     my $quilt = $self->build_quilt_object($dir);
     $msg = $quilt->find_problems();

Message #107 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>

To: 1007717-done@bugs.debian.org

Cc: 737634@bugs.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, debian-policy@lists.debian.org

Subject: Bug#1007717: Native source package format with non-native version

Date: Mon, 27 Jun 2022 09:23:25 -0700

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.

-- 
Sean Whitton

Message #112 received at 737634@bugs.debian.org (full text, mbox, reply):

From: Dimitri John Ledkov <dimitri.ledkov@canonical.com>

To: 737634@bugs.debian.org

Subject: Re: Bug#1007717: Native source package format with non-native version

Date: Tue, 2 Jan 2024 12:02:49 +0000

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.

Message #117 received at 737634-submitter@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: 737634-submitter@bugs.debian.org

Subject: Bug#737634 in package dpkg marked as pending

Date: Mon, 2 Jun 2025 03:41:43 +0200 (CEST)

Control: tag 737634 pending

Hi!

Bug #737634 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

    https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=40cd7dd9d

---
Add vendor specific support for fuzzy source vs version nativeness

There's been an ongoing push to distort the native source package
concept, where this is a source of both accidental source package
construction, where even warnings have been shown to not be enough.

It has been argued this is a requirement for mainly two broad cases,
one is for native metapackages tracking non-native packages, where
the desire is to use the same versioning scheme (but with no version
remapping), and for either CI or VCS based workflows, where some of
the people involved either consider none of the proposed alternative
solutions acceptable, or consider that source packages are obsolete
and should not even be used anymore anyway, and undermining them is
clearly an acceptable price that others should pay.

This sets us back into making the packaging and its concepts more
difficult to grasp and handle, both for existing maintainers and
newcomers, and also for tool maintainers.

We need to add the notion of fuzzy nativeness, where a native source
package does not have a coherent native source version, so that vendors
that are forcing this sloppiness through, can have it without affecting
the default non-vendor case. Unfortunately this affects Debian and
derivatives. Which means using a method like Dpkg::Version->is_native()
has unreliable and non-portable semantics, so we deprecate that now
as well, and will be removed in the future.

Closes: #737634

Send a report that this bug log contains spam.