Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

Hello,

On Fri 02 Apr 2021 at 10:22AM -07, Russ Allbery wrote:

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index a21a510..2fd6868 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -582,20 +582,17 @@ The three components here are:
>  alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
>  tilde) and is compared in the same way as the ``upstream_version`` is.
>
> -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.
> +It is conventional to restart the ``debian_revision`` at ``1`` each
> +time the ``upstream_version`` is increased.
>
> -It is conventional to restart the ``debian_revision`` at ``1``
> -each time the ``upstream_version`` is increased.
> +The package management system will break the version number apart at
> +the last hyphen in the string (if there is one) to determine the
> +``upstream_version`` and ``debian_revision``. The absence of a
> +``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
>
> -The package management system will break the version number apart
> -at the last hyphen in the string (if there is one) to determine
> -the ``upstream_version`` and ``debian_revision``. The absence of a
> -``debian_revision`` is equivalent to a ``debian_revision`` of
> -``0``.
> +Presence of the ``debian_revision`` part indicates this package is a
> +non-native package (see :ref:`s-source-packages`).  Absence indicates
> +the package is a native package.
>
>  When comparing two version numbers, first the epoch of each are
>  compared, then the ``upstream_version`` if epoch is equal, and then
> @@ -625,6 +622,8 @@ These two steps (comparing and removing initial non-digit 
> strings and
>  initial digit strings) are repeated until a difference is found or both
>  strings are exhausted.
>
> +.. _s-avoid-epochs:
> +
>  Epochs should be used sparingly
>  ^^^
>
> @@ -639,13 +638,132 @@ Epochs should not be used when a package needs to be 
> rolled back.
>  In that case, use the ``+really`` convention: for example, if you
>  uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2,
>  call your reverting upload something like ``2.3+really2.2-1``.
> -Eventually, when we upload upstream 2.4, the +really part can go away.
> +Eventually, when we upload upstream 2.4, the ``+really`` part can go away.
>
>  Epochs are also not intended to cope with version
>  numbers containing strings of letters which the package management
>  system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
>  orderings.  [#]_
>
> +Special version conventions
> +^^^
> +
> +The following special version numbering conventions are used in the Debian
> +archive:
> +
> +- The absence of ``debian_revision``, and therefore of a hyphen in the
> +  version number, indicates that the package is native.
> +
> +- The presence of ``+really`` in the ``upstream_version`` component
> +  indicates that a newer upstream version has been rolled back to an older
> +  upstream version.  The part of the ``upstream_version`` component
> +  following ``+really`` is the true upstream version.  See
> +  :ref:`s-avoid-epochs` for an example of when this is used.
> +
> +Non-maintainer uploads:
> +
> +- ``debian_revision`` components ending in ``.`` (period) followed by a
> +  number indicate this version of the non-native package was uploaded by
> +  someone other than the maintainer (an NMU or non-maintainer upload).
> +  This is used for a source package upload; for uploads of only binary
> +  packages without source changes, see the binary NMU convention below.
> +
> +- ``upstream_version`` components in native packages ending in ``+nmu``
> +  followed by a number indicate an NMU of a native package.  As with the
> +  convention for non-native packages, this is used for a source package
> +  upload, not for uploads of only binary packages without source changes.
> +
> +- ``upstream_version`` components in native packages or
> +  ``debian_revision`` components in non-native packages ending in ``+b``
> +  followed by a number indicate a binary NMU: an upload of a binary
> +  package without any source changes and hence without any corresponding
> +  source package upload or version change.
> +
> +Stable updates:
> +
> +- ``upstream_version`` components in native packages ending in ``+debNuX``
> +  indicate a stable update.  This is a version of the package uploaded
> +  directly to a stable release, and the version is chosen to sort before
> +  any later version of the package uploaded to Debian's unstable or a
> +  

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Hi Sam,

Russ> Thanks for the review!  There's now a newer version of this
Russ> diff adjusted for a flaw that Simon pointed out.  It's
Russ> sufficiently different from the original diff that I don't
Russ> want to count seconds for the original as seconds for it.
Russ> It's at:

Russ> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288#280

Aargh, sorry.
I read Simon's message, and then read your earlier patch in the wrong
order, and thought, wow Russ managed to come up with a way to address
Simon's issue that was shorter than I thought.
(Not realizing that I was responding to a message before you had
addressed it).

I'm happy to second the newer patch in #280 although I have one
non-blocking comment.

+- ``upstream_version`` components in native packages ending in
``+debNuX``
+  indicate a stable update.  This is a version of the package uploaded
+  directly to a stable release, and the version is chosen to sort
before
+  any later version of the package uploaded to Debian's unstable or a
+  later stable distribution.  ``N`` is the major version number of the
+  Debian stable release to which the package was uploaded, and ``X`` is
a
+  number, starting at 1, that is increased for each stable upload of
this
+  package.
+


Because this comes before [+~]debXuN in the Debian revision, it's easy
for a reader to treat this as a common case on first reading.
I think it's much more common for us to have the stable update noted in
a Debian revision than in the upstream revision, and we should say this.


I hugely confused myself by missing the word "native" in the above  and
was starting to think about why we'd ever mark a stable update in the
upstream version of a non-native package.
Your text does in fact include native, but this illustrates how even for
a experienced packager, having the uncommon case first can  lead to
confusion.

--Sam


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> Here is an updated diff that documents the most
> Russ> well-understood version conventions in the Debian archive.
> Russ> More could certainly be added; this is just a first start that
> Russ> addresses this specific bug.

> Russ> This revised patch is less aggressive about defining native
> Russ> packages to only mean packages with no existence external to
> Russ> Debian.  I also found that we never define upstream, which
> Russ> seems like a critical concept, so I added a definition to the
> Russ> Definitions section.

> second.

Hi Sam,

Thanks for the review!  There's now a newer version of this diff adjusted
for a flaw that Simon pointed out.  It's sufficiently different from the
original diff that I don't want to count seconds for the original as
seconds for it.  It's at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542288#280

-- 
Russ Allbery (r...@debian.org)  

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Here is an updated diff that documents the most
Russ> well-understood version conventions in the Debian archive.
Russ> More could certainly be added; this is just a first start that
Russ> addresses this specific bug.

Russ> This revised patch is less aggressive about defining native
Russ> packages to only mean packages with no existence external to
Russ> Debian.  I also found that we never define upstream, which
Russ> seems like a critical concept, so I added a definition to the
Russ> Definitions section.
second.


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Holger Levsen]

On Fri, Apr 02, 2021 at 10:26:47AM -0700, Russ Allbery wrote:
> I'll therefore propose that we move the discussion of whether to give
> stronger advice on when to use native packages to a separate bug.  Once
> this is merged, there will be some text in Policy defining native
> packages, so it will be easier to work on that.
> 
> Sound good?

sounds good, thanks!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Holger Levsen  writes:

> I'm not sure if in this regard I would have liked the previous version
> better, as the paragraph about native packages is the only one which I
> would like to see extended to explain that it has been observed that
> packages we thought were native to Debian were not really native to
> Debian at all and require modifications in Debian downstream
> distributions, which are harder to do when the packages are native (eg
> modified orig.tar's despite no upstream changes).

This is generally my opinion as well, but I know there are other folks who
disagree, and I'm therefore not sure whether this has consensus.  (Native
packages are a lot simpler.)  I decided to take the easy way out and note
that this bug was originally about documenting NMU and stable upload
version conventions, so setting policy for when people should use native
packages is a bit out of scope.

I'll therefore propose that we move the discussion of whether to give
stronger advice on when to use native packages to a separate bug.  Once
this is merged, there will be some text in Policy defining native
packages, so it will be easier to work on that.

Sound good?

-- 
Russ Allbery (r...@debian.org)  

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Simon McVittie  writes:

> The other way is to repackage the new upstream release from first
> principles, either because it's a new release from an upstream branch
> that's older than the one in testing/unstable (like src:flatpak in
> Debian 10), or because testing/unstable already has packaging changes
> that aren't suitable for stable (like src:dbus in Debian 10). In this
> case it would be misleading to use a version number like
> flatpak_1.2.5-1~deb10u1 (because 1.2.5-1 never existed) or
> dbus_1.12.20-1~deb10u1 (because 1.12.20-1 did exist, but the version of
> dbus in stable was not based on it, and does not have the downstream
> changes from that version). Instead, the convention that has emerged is
> to use 0+deb10u1, by analogy with the convention that an NMU introducing
> a new upstream release has revision number 0.1.

Ah, thanks for this.  I wasn't aware this convention existed.

Here's a new draft, which is unfortunately quite a bit longer because it's
hard to make this clear.  I also added the +really convention explicitly,
since it's mentioned immediately above, and noted that the stable update
and backport conventions can, in rare circumstances, stack.

-- 
Russ Allbery (r...@debian.org)  

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..2fd6868 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -582,20 +582,17 @@ The three components here are:
 alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
 tilde) and is compared in the same way as the ``upstream_version`` is.
 
-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.
+It is conventional to restart the ``debian_revision`` at ``1`` each
+time the ``upstream_version`` is increased.
 
-It is conventional to restart the ``debian_revision`` at ``1``
-each time the ``upstream_version`` is increased.
+The package management system will break the version number apart at
+the last hyphen in the string (if there is one) to determine the
+``upstream_version`` and ``debian_revision``. The absence of a
+``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
 
-The package management system will break the version number apart
-at the last hyphen in the string (if there is one) to determine
-the ``upstream_version`` and ``debian_revision``. The absence of a
-``debian_revision`` is equivalent to a ``debian_revision`` of
-``0``.
+Presence of the ``debian_revision`` part indicates this package is a
+non-native package (see :ref:`s-source-packages`).  Absence indicates
+the package is a native package.
 
 When comparing two version numbers, first the epoch of each are
 compared, then the ``upstream_version`` if epoch is equal, and then
@@ -625,6 +622,8 @@ These two steps (comparing and removing initial non-digit strings and
 initial digit strings) are repeated until a difference is found or both
 strings are exhausted.
 
+.. _s-avoid-epochs:
+
 Epochs should be used sparingly
 ^^^
 
@@ -639,13 +638,132 @@ Epochs should not be used when a package needs to be rolled back.
 In that case, use the ``+really`` convention: for example, if you
 uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2,
 call your reverting upload something like ``2.3+really2.2-1``.
-Eventually, when we upload upstream 2.4, the +really part can go away.
+Eventually, when we upload upstream 2.4, the ``+really`` part can go away.
 
 Epochs are also not intended to cope with version
 numbers containing strings of letters which the package management
 system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
 orderings.  [#]_
 
+Special version conventions
+^^^
+
+The following special version numbering conventions are used in the Debian
+archive:
+
+- The absence of ``debian_revision``, and therefore of a hyphen in the
+  version number, indicates that the package is native.
+
+- The presence of ``+really`` in the ``upstream_version`` component
+  indicates that a newer upstream version has been rolled back to an older
+  upstream version.  The part of the ``upstream_version`` component
+  following ``+really`` is the true upstream version.  See
+  :ref:`s-avoid-epochs` for an example of when this is used.
+
+Non-maintainer uploads:
+
+- ``debian_revision`` components ending in ``.`` (period) followed by a
+  number indicate this version of the non-native package was uploaded by
+  someone other than the maintainer (an NMU or non-maintainer upload).
+  This is used for a source package upload; for uploads 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Simon McVittie]

On Thu, 01 Apr 2021 at 18:17:59 -0700, Russ Allbery wrote:
> +- ``upstream_version`` components in native packages or
> +  ``debian_revision`` components in non-native packages ending in
> +  ``~debNuX`` also indicate a stable update, but of a different type.
> +  This version convention indicates that the stable version of the package
> +  was updated to a new upstream release, as distinct from the ``+debNuX``
> +  convention that indicates additional changes were applied to the
> +  existing stable release.  ``N`` and ``X`` mean the same as with
> +  ``+debNuX``.

I don't think this is quite it.

For me, ~debNu1 implies that a stable update was made by taking a newer
Debian package (typically from unstable) - not necessarily a new upstream
release! - and backporting it in its entirety, mechanically equivalent to
a ~bpo version but released to all users of stable rather than just those
who have opted-in to backports.

src:pango1.0 in Debian 10 is an example of this: we fixed CVE-2019-1010238
in testing/unstable by applying a patch (1.42.4-6 was vulnerable,
1.42.4-7 was fixed). We could have continued by fixing CVE-2019-1010238
in stable as 1.42.4-6+deb10u1, but the result would have been functionally
equivalent to 1.42.4-7, so it seemed clearer to just take 1.42.4-7 and
rebuild it for Debian 10 as 1.42.4-7~deb10u1. We later repeated the
process for 1.42.4-8 with some non-security fixes.

If the stable version of the package was updated to a new upstream release
instead, there are two ways that can happen. One way is to take the version
from testing/unstable and rebuild it in stable, like src:openjdk-11 in
Debian 10: 11.0.9.1+1-1 was uploaded to unstable first, then rebuilt
in Debian 10 as 11.0.9.1+1-1~deb10u1.

The other way is to repackage the new upstream release from first
principles, either because it's a new release from an upstream branch
that's older than the one in testing/unstable (like src:flatpak in Debian
10), or because testing/unstable already has packaging changes that aren't
suitable for stable (like src:dbus in Debian 10). In this case it would be
misleading to use a version number like flatpak_1.2.5-1~deb10u1 (because
1.2.5-1 never existed) or dbus_1.12.20-1~deb10u1 (because 1.12.20-1 did
exist, but the version of dbus in stable was not based on it, and does
not have the downstream changes from that version). Instead, the convention
that has emerged is to use 0+deb10u1, by analogy with the convention that
an NMU introducing a new upstream release has revision number 0.1.

~debNuX for X > 1 indicates subsequent stable-specific changes applied
on top of to a ~debNu1 version.

(Sorry, I'm not sure how to express all this in a paragraph or two...)

smcv

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Holger Levsen]

Hi Russ,

On Thu, Apr 01, 2021 at 06:17:59PM -0700, Russ Allbery wrote:
> Here is an updated diff that documents the most well-understood version
> conventions in the Debian archive.  More could certainly be added; this is
> just a first start that addresses this specific bug.

thank you for this, I've reviewed it and am generally very happy with these
changes.

> This revised patch is less aggressive about defining native packages to
> only mean packages with no existence external to Debian. 

I'm not sure if in this regard I would have liked the previous version better,
as the paragraph about native packages is the only one which I would like to
see extended to explain that it has been observed that packages we thought 
were native to Debian were not really native to Debian at all and require
modifications in Debian downstream distributions, which are harder to do
when the packages are native (eg modified orig.tar's despite no upstream 
changes).

src:piuparts is one example for this where this is even annoying within
Debian, as eg piuparts 1.1.2 was uploaded to sid and then that orig tarball
cannot be used for the upload to backports.

Also big/huge native packages are also annoying to maintain when one has
to do small packaging changes and each time has to upload huge orig.tar.
This was annoying when src:debian-edu-artwork was 50-100mb and native, today
that package is 8mb and non-native.

> I think this change is ready for seconds.

All that said, I'm still happy to second this! :)
 
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index a21a510..cd7daaa 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -582,20 +582,17 @@ The three components here are:
>  alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
>  tilde) and is compared in the same way as the ``upstream_version`` is.
>  
> -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.
> +It is conventional to restart the ``debian_revision`` at ``1`` each
> +time the ``upstream_version`` is increased.
>  
> -It is conventional to restart the ``debian_revision`` at ``1``
> -each time the ``upstream_version`` is increased.
> +The package management system will break the version number apart at
> +the last hyphen in the string (if there is one) to determine the
> +``upstream_version`` and ``debian_revision``. The absence of a
> +``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
>  
> -The package management system will break the version number apart
> -at the last hyphen in the string (if there is one) to determine
> -the ``upstream_version`` and ``debian_revision``. The absence of a
> -``debian_revision`` is equivalent to a ``debian_revision`` of
> -``0``.
> +Presence of the ``debian_revision`` part indicates this package is a
> +non-native package (see :ref:`s-source-packages`).  Absence indicates
> +the package is a native package.
>  
>  When comparing two version numbers, first the epoch of each are
>  compared, then the ``upstream_version`` if epoch is equal, and then
> @@ -646,6 +643,83 @@ numbers containing strings of letters which the package 
> management
>  system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
>  orderings.  [#]_
>  
> +Special version conventions
> +^^^
> +
> +The following special version numbering conventions are used in the Debian
> +archive:
> +
> +- The absence of ``debian_revision``, and therefore of a hyphen in the
> +  version number, indicates that the package is native.
> +
> +- ``debian_revision`` components ending in ``.`` (period) followed by a
> +  number indicate this version of the non-native package was uploaded by
> +  someone other than the maintainer (an NMU or non-maintainer upload).
> +  This is used for a source package upload; for uploads of only binary
> +  packages without source changes, see the binary NMU convention below.
> +
> +- ``upstream_version`` components in native packages ending in ``+nmu``
> +  followed by a number indicate an NMU of a native package.  As with the
> +  convention for non-native packages, this is used for a source package
> +  upload, not for uploads of only binary packages without source changes.
> +
> +- ``upstream_version`` components in native packages or
> +  ``debian_revision`` components in non-native packages ending in ``+b``
> +  followed by a number indicate a binary NMU: an upload of a binary
> +  package without any source changes and hence without any corresponding
> +  source package upload or version change.
> +
> +- ``upstream_version`` 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Here is an updated diff that documents the most well-understood version
conventions in the Debian archive.  More could certainly be added; this is
just a first start that addresses this specific bug.

This revised patch is less aggressive about defining native packages to
only mean packages with no existence external to Debian.  I also found
that we never define upstream, which seems like a critical concept, so I
added a definition to the Definitions section.

I've also reviewed the places where the Developer's Reference talks about
similar issues and I believe this is consistent with it.

I think this change is ready for seconds.

-- 
Russ Allbery (r...@debian.org)  

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..cd7daaa 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -582,20 +582,17 @@ The three components here are:
 alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
 tilde) and is compared in the same way as the ``upstream_version`` is.
 
-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.
+It is conventional to restart the ``debian_revision`` at ``1`` each
+time the ``upstream_version`` is increased.
 
-It is conventional to restart the ``debian_revision`` at ``1``
-each time the ``upstream_version`` is increased.
+The package management system will break the version number apart at
+the last hyphen in the string (if there is one) to determine the
+``upstream_version`` and ``debian_revision``. The absence of a
+``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
 
-The package management system will break the version number apart
-at the last hyphen in the string (if there is one) to determine
-the ``upstream_version`` and ``debian_revision``. The absence of a
-``debian_revision`` is equivalent to a ``debian_revision`` of
-``0``.
+Presence of the ``debian_revision`` part indicates this package is a
+non-native package (see :ref:`s-source-packages`).  Absence indicates
+the package is a native package.
 
 When comparing two version numbers, first the epoch of each are
 compared, then the ``upstream_version`` if epoch is equal, and then
@@ -646,6 +643,83 @@ numbers containing strings of letters which the package management
 system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
 orderings.  [#]_
 
+Special version conventions
+^^^
+
+The following special version numbering conventions are used in the Debian
+archive:
+
+- The absence of ``debian_revision``, and therefore of a hyphen in the
+  version number, indicates that the package is native.
+
+- ``debian_revision`` components ending in ``.`` (period) followed by a
+  number indicate this version of the non-native package was uploaded by
+  someone other than the maintainer (an NMU or non-maintainer upload).
+  This is used for a source package upload; for uploads of only binary
+  packages without source changes, see the binary NMU convention below.
+
+- ``upstream_version`` components in native packages ending in ``+nmu``
+  followed by a number indicate an NMU of a native package.  As with the
+  convention for non-native packages, this is used for a source package
+  upload, not for uploads of only binary packages without source changes.
+
+- ``upstream_version`` components in native packages or
+  ``debian_revision`` components in non-native packages ending in ``+b``
+  followed by a number indicate a binary NMU: an upload of a binary
+  package without any source changes and hence without any corresponding
+  source package upload or version change.
+
+- ``upstream_version`` components in native packages or
+  ``debian_revision`` components in non-native packages ending in
+  ``+debNuX`` indicate a stable update.  This is a version of the package
+  uploaded directly to a stable release, and the version is chosen to sort
+  before any later version of the package uploaded to Debian's unstable
+  distribution.  ``N`` is the major version number of the Debian stable
+  release to which the package was uploaded, and ``X`` is a number,
+  starting at 1, that is increased for each stable upload of this package.
+
+  For example, suppose Debian 10 released with a package with version
+  ``1.4-5``.  If that package later receives a stable update in Debian 10,
+  the first update would have the version ``1.4-5+deb10u1``.  A subsequent
+  update would have version ``1.4-5+deb10u2``.  These numbers are designed
+  to sort earlier than ``1.4-6``, the version number that would be used
+  for the next 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

Hello Russ,

On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
> I thought there actually was a consensus that it's terrible.  I certainly
> think it's not good practice.  I would recommend against anyone doing
> this, speaking as someone who maintains lots of upstream software that I
> also package for Debian, and therefore would rather not document it in
> Policy, unless we're going to say not to do it.

Thank you for your response.  I trust your judgement about this
consensus.  So I withdraw my comments regarding your patch.

So as not to let this bug get off-topic, I'll send you some other
comments about using native packages privately.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Wouter Verhelst]

On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
[...maintaining non-Debian-specific software as a native package...]
> I certainly think it's not good practice.

I think it depends on the particulars of the situation.

I am upstream for two of the packages I maintain for Debian: nbd and
fdpowermon.

For nbd, I maintain it as an upstream package on sourceforge and github,
and as a non-native Debian package.

For fdpowermon, I just maintain it as a native package. I do this,
simply, because the package is fairly trivial -- the most important bit
is a (currently) 573-line perl script (and that's including POD
documentation). While it's certainly possible to ship an "upstream"
Makefile.PL or some such with this package, that feels like overkill and
generally not worth it. Additionally, the packaging is so simple that
updating the package for just the packaging is rare, if it even happens
at all, so just about every update I've ever done was relevant for
people who did not use Debian, too.

While I agree that Debian is not a general software distribution
platform, and that therefore shipping software like this isn't
necessarily a good idea, for me as a Debian developer it is
significantly easier to just maintain it this way and not have to worry
about the extra overhead (even if it's a pretty small overhead) that an
"upstream" release would involve.

[...]
> Bumping the minor version for things that no one cares about (because they
> only affect people consuming it from Debian) is probably between you and
> your users, although I think it's poor practice and would be vaguely
> irritated by it.

I can see why that might be the case, but given that in the case that I
quote above that is actually quite rare, I'm not sure it's a problem.

> But the stronger argument against this approach is NMUs and change of
> maintainership.  As soon as such a package is NMU'd for whatever
> reason, or if you no longer have time to maintain the package for
> Debian but are still developing it upstream, the native package status
> gets really awkward.

I'm not sure this is true.

By uploading a native package into Debian, I take the "risk" that at
some point someone will have to do an NMU, yes. Indeed, if I instead
hosted the package on some upstream hosting site, then nobody but me
will be able to do releases of fdpowermon. But that's not a major issue;
I trust that my fellow developers won't abuse that right (indeed, they
don't usually do so).

If I ever find myself in the situation where I stop maintaining
fdpowermon in Debian but continue maintaining it upstream, then
converting the package from a native to a non-native one is fairly
trivial. In fact, I've occasionally uploaded nbd as a native package by
accident, because dak doesn't actually care, and neither do our build
tools (when using source format 1.0). As such, if that situation ever
happens, then moving to a non-native package is trivial, and there is no
awkwardness.

[...]
> I've also repeatedly had the experience as upstream maintainer that I
> actually do need to carry a Debian-specific patch for a while, since
> Debian needs some quick fix that I don't want to take upstream in the same
> form.

Indeed; for nbd, I've occasionally had to do that as well. Usually it's
a cherry-pick from upstream master or some such, where a bug was first
exposed in one of our more obscure ports; and while I do want to release
it upstream, just doing a new upstream release just so I can release a
bugfix for alpha or hurd or whatnot isn't really worth it.

For a simple perl script which by its very nature has little portability
issues and therefore small chances for requiring such patches, I don't
think it's worth fussing about though.

A somewhat more complicated example is ikiwiki; when Joey was still
maintaining it for Debian (before he resigned from the project), it was
also a native package. At the time, the package version number was just
the git checkout date, as in, "we don't really do upstream releases,
what's in Debian is just a snapshot from the git repository". That, too,
seems like a reasonable approach to me.

I guess what I'm saying is that it really depends on the particulars of
how you maintain the software; and that while in general it's probably a
bad idea, there can be corner cases where it isn't necessarily a bad
idea, can even be a good idea, and certainly takes away some overhead
and extra work that wouldn't be necessary at all if not for the fact
that you're doing a non-native version and therefore need to do an
"upstream" release before you can do a Debian release.

Regards,

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[gregor herrmann]

On Sat, 01 Jul 2017 08:52:29 -0700, Russ Allbery wrote:

> Sean Whitton  writes:
> 
> > Some people frown upon this practice, but there are more than one of us
> > that do it, so probably worth mentioning in policy as a secondary use of
> > native packages (possibly a footnote, due to lack of consensus?  There
> > is certainly not a consensus that it's terrible).
> I thought there actually was a consensus that it's terrible.  I certainly
> think it's not good practice.  I would recommend against anyone doing
> this, speaking as someone who maintains lots of upstream software that I
> also package for Debian, and therefore would rather not document it in
> Policy, unless we're going to say not to do it.

FWIW, I agree, and I also think that this as close to a consensus as
any issue in Debian can get.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: U2: When I Look At The World


signature.asc
Description: Digital Signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Sean Whitton  writes:

> Native packages are also used for software that is intended for use
> beyond Debian, but where the upstream maintainer also maintains the
> Debian package.  In such cases, the Debian revision and orig tarballs
> represent needless overhead (tweaks to the packaging can use an
> increment to the minor version number, or similar).

> Some people frown upon this practice, but there are more than one of us
> that do it, so probably worth mentioning in policy as a secondary use of
> native packages (possibly a footnote, due to lack of consensus?  There
> is certainly not a consensus that it's terrible).

I thought there actually was a consensus that it's terrible.  I certainly
think it's not good practice.  I would recommend against anyone doing
this, speaking as someone who maintains lots of upstream software that I
also package for Debian, and therefore would rather not document it in
Policy, unless we're going to say not to do it.

Bumping the minor version for things that no one cares about (because they
only affect people consuming it from Debian) is probably between you and
your users, although I think it's poor practice and would be vaguely
irritated by it.  But the stronger argument against this approach is NMUs
and change of maintainership.  As soon as such a package is NMU'd for
whatever reason, or if you no longer have time to maintain the package for
Debian but are still developing it upstream, the native package status
gets really awkward.  At that point, the package is diverging from
upstream, but all the normal mechanisms to handle that divergence with
patch sets and whatnot are no longer available.

I've also repeatedly had the experience as upstream maintainer that I
actually do need to carry a Debian-specific patch for a while, since
Debian needs some quick fix that I don't want to take upstream in the same
form.  Which means that I want to use the patch handling mechanisms of
Debian even for myself.  And the overhead is basically nonexistent once
you get your tools configured and a workflow set up.

Whenever this came up on debian-mentors, it seemed to me like there was
fairly strong consensus that native status should only be used for
software with no independent existence, and as soon as there's a separate
upstream release and Debian packaging, it's better to just do the setup
work to have a non-native package.

-- 
Russ Allbery (r...@debian.org)   

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

On Sat, Jul 01, 2017 at 04:46:21PM +0100, Adam D. Barratt wrote:
> fwiw, I can't think of situations where -deb9u1 would ever be used.
> Either a selected set of changes were applied to the package in stable,
> which would be +debXuY, or a newer upload was backported in its
> entirety, which would be ~debXuY as above.

Sorry, I meant s/-deb9u1/+deb9u1/.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

On Sun, Jun 25, 2017 at 02:08:05PM -0700, Russ Allbery wrote:
> Concerns, objections, seconds?

Thank you for working on this.

> +A native package is software written specifically for Debian
> +whose canonical distribution format is as a Debian package.
> +Native packages have no separate upstream source in their
> +source package representation and no separate Debian
> +revision in their version numbers.  Native packages are an
> +exception: most Debian packages are "non-native" and have
> +source packages composed of an upstream software release and
> +separate Debian-specific modifications.

Native packages are also used for software that is intended for use
beyond Debian, but where the upstream maintainer also maintains the
Debian package.  In such cases, the Debian revision and orig tarballs
represent needless overhead (tweaks to the packaging can use an
increment to the minor version number, or similar).

Some people frown upon this practice, but there are more than one of us
that do it, so probably worth mentioning in policy as a secondary use of
native packages (possibly a footnote, due to lack of consensus?  There
is certainly not a consensus that it's terrible).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

On Sun, Jun 25, 2017 at 04:01:43PM -0700, Russ Allbery wrote:
> > One rarer case is missing here:
> 
> > 1.2.3-4~deb9u1
> > Everything in 1.2.3-4 from unstable was in fact needed in Debian
> > 9, so it was simply rebuilt for Debian 9 and uploaded there
> > (prominent examples: firefox-esr, intel-microcode)
> 
> Is this widespread enough to be worth describing?  It's kind of hard to
> describe.

I for one had assumed that there was no difference between -deb9u1 and
~deb9u1, so I'd like to see it documented.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Bill Allombert]

On Sun, Jun 25, 2017 at 02:08:05PM -0700, Russ Allbery wrote:
> It's been a while since the last update to this thread and proposed
> wording about the special version numbering conventions in use in Debian,
> and in the meantime things have settled out a bit more and we have a
> pretty firm consensus on how to handle special versions.  I'd therefore
> like to resurrect this thread and see if we can agree on some wording.
> 
> The patch below adds a definition of native packages to our definitions
> section and documents the following version number conventions:
> 
> - Native packages
> - NMUs of native and non-native packages
> - binNMUs
> - Stable updates
> - Backports
> 
> I think these are all fairly consistent and widely agreed-on at this
> point.
> 
> Concerns, objections, seconds?

Maybe we should check whether this is consistent with the devref, since
it covers the same ground.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Simon McVittie  writes:
> On Sun, 25 Jun 2017 at 14:08:05 -0700, Russ Allbery wrote:

>> +upstream_version components in
>> +native packages ending in +nmu followed
>> +by a number indicate an NMU of a native package.

> I thought 1.2.3-4+nmu1 was also allowed as an alternative to 1.2.3-4.1?
> But perhaps that's non-standard (it's certainly redundant).

There's some previous discussion in the bug.  The summary is that this was
proposed and is sometimes used, but pretty much everyone uses the 4.1
syntax still, so it doesn't seem to really have consensus.

Note that this list is not exclusive; there may be version numbering
conventions that aren't documented.  I just wanted to get down the most
likely ones that people will encounter.

>> +N is the major version number
>> +of the Debian stable release to which the package was
>> +package uploaded directly to a stable release, and the

> You have some duplicated lines here I think.

Argh.  For some reason, less constantly messes with me when I cut and
paste diffs instead of saving them to a file and including them directly.
I could have sworn I configured it to never use partial pages.

Included is the correct version of the patch.

> One rarer case is missing here:

> 1.2.3-4~deb9u1
>   Everything in 1.2.3-4 from unstable was in fact needed in Debian
>   9, so it was simply rebuilt for Debian 9 and uploaded there
>   (prominent examples: firefox-esr, intel-microcode)

Is this widespread enough to be worth describing?  It's kind of hard to
describe.

diff --git a/policy.xml b/policy.xml
index 7ba5fc0..fbc53c9 100644
--- a/policy.xml
+++ b/policy.xml
@@ -357,6 +357,21 @@
   
 
 
+  native package
+  
+
+  A native package is software written specifically for Debian
+  whose canonical distribution format is as a Debian package.
+  Native packages have no separate upstream source in their
+  source package representation and no separate Debian
+  revision in their version numbers.  Native packages are an
+  exception: most Debian packages are "non-native" and have
+  source packages composed of an upstream software release and
+  separate Debian-specific modifications.
+
+  
+
+
   UTF-8
   
 
@@ -589,13 +604,10 @@
 
   must not require or recommend a package outside of
   main for compilation or execution
-  (thus, the package must not declare a
-  Pre-Depends, Depends,
-  Recommends,
-  Build-Depends,
-  Build-Depends-Indep, or
-  Build-Depends-Arch relationship on a
-  non-main package),
+  (thus, the package must not declare a "Pre-Depends",
+  "Depends", "Recommends", "Build-Depends",
+  "Build-Depends-Indep", or "Build-Depends-Arch" relationship
+  on a non-main package),
 
   
   
@@ -3725,11 +3737,11 @@ Package: libc6
   
 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.
+contain a hyphen.  This format represents a native
+package: a piece of software 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.
   
   
 It is conventional to restart the
@@ -3814,6 +3826,110 @@ Package: libc6
 
   
 
+
+
+  Special version conventions
+
+  
+The following special version numbering conventions are used in
+the Debian archive:
+  
+  
+
+  
+The absence of debian_revision,
+and therefore of a hyphen in the version number, indicates
+that the package is native.
+  
+
+
+  
+debian_revision components
+ending in . followed by a number
+indicate this version of the non-native package was
+uploaded by someone other than the maintainer (an NMU or
+non-maintainer upload).  This is used for a source package
+

Re: Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Simon McVittie]

On Sun, 25 Jun 2017 at 14:08:05 -0700, Russ Allbery wrote:
> +upstream_version components in
> +native packages ending in +nmu followed
> +by a number indicate an NMU of a native package.

I thought 1.2.3-4+nmu1 was also allowed as an alternative to 1.2.3-4.1?
But perhaps that's non-standard (it's certainly redundant).

> +N is the major version number
> +of the Debian stable release to which the package was
> +package uploaded directly to a stable release, and the

You have some duplicated lines here I think.

One rarer case is missing here:

1.2.3-4~deb9u1
Everything in 1.2.3-4 from unstable was in fact needed in Debian
9, so it was simply rebuilt for Debian 9 and uploaded there
(prominent examples: firefox-esr, intel-microcode)

Regards,
S

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Raphael Hertzog]

On Fri, 04 Sep 2009, Steve Langasek wrote:
 I thought there had been one in the sarge timeframe; but I'm not going to go
 digging any farther to confirm this.  Yes, the problem is more or less
 theoretical.

AFAIK, dak always refused uploads that would create such problems so
maintainers have to find another work around... and it's after the reject
that questions are asked on what would be the proper version number (and
where we don't have a proper answer).

The rules have been loosened recently for proposed updates however:
http://git.debian.org/?p=users/hertzog/dak.git;a=commitdiff;h=485eac6e5a57d38bfdc7f84aaf982db02405e62e

An interesting check would be to verify how many packages in lenny or
squeeze have higher version than in unstable currently due to this.

The rules checked at upload are in dak.conf:
http://git.debian.org/?p=users/hertzog/dak.git;a=blob_plain;f=config/debian/dak.conf;hb=04c242d16f7194e5bf7fddf3109ace61bc16be58

See VersionChecks in each suite definition.

Cheers,
-- 
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Lucas Nussbaum]

On 05/09/09 at 14:26 +0200, Raphael Hertzog wrote:
 On Fri, 04 Sep 2009, Steve Langasek wrote:
  I thought there had been one in the sarge timeframe; but I'm not going to go
  digging any farther to confirm this.  Yes, the problem is more or less
  theoretical.
 
 AFAIK, dak always refused uploads that would create such problems so
 maintainers have to find another work around... and it's after the reject
 that questions are asked on what would be the proper version number (and
 where we don't have a proper answer).
 
 The rules have been loosened recently for proposed updates however:
 http://git.debian.org/?p=users/hertzog/dak.git;a=commitdiff;h=485eac6e5a57d38bfdc7f84aaf982db02405e62e
 
 An interesting check would be to verify how many packages in lenny or
 squeeze have higher version than in unstable currently due to this.

Only debian-installer. Checked using UDD with:
select l.source, l.version, u.version
from sources l, sources u
where l.source = u.source
and l.distribution = 'debian' and u.distribution = 'debian'
and l.release = 'lenny' and u.release = 'sid'
and l.version  u.version;
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Steve Langasek]

On Wed, Aug 26, 2009 at 11:29:57PM -0500, Manoj Srivastava wrote:
 So, we should have:

 ,
 |  Format:
 | Version:=  [epoch`:']upstream_version[`-'debian_revision]
 |  Native Package NMU's:
 | Version =~ m/\+nmu\d+$/
 |  Binary Only NMU's:
 |Version =~ m/\+b\d+$/
 `

 The next tgree are tentative:
 ,
 |  Non-native package NMU:
 |Version =~ m/\-\.\d+$/
 `
 This is tentative since I can't see why we need to outlaw
  packages adding \+nmu\d+ even on non-native packages. Perhaps policy
  should butt out here, if the pattern is different for non-native NMU's
  than for Native package NMU's.

Thus far, consistent with current practice.

 ,
 |  Stable Security NMU's
 |Version =~  m/\+deb\d\d.\d+$/
 |  Testing Security NMU's
 |   Version =~ m/\+debt\d\d.\d+$/
 `
 These last two do not have buy in from the security team, as far
  as I can tell.

Right, since they're not actually being used by the security team I don't
think there's anything to be gained by declaring in policy that the security
team /should/ use this.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Steve Langasek]

On Tue, Sep 01, 2009 at 11:14:04PM +0200, Julien Cristau wrote:
 On Tue, Sep  1, 2009 at 14:06:17 -0700, Steve Langasek wrote:

  On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
   On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:

That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
3. etch is released with P 1.0-1.
4. A security bug is found in P.

   Does this actually happen?  How often?

  Often enough that it's been discussed repeatedly over the years; not often
  enough that anyone has fixed it. :)

 Every time I've seen it discussed, it was by people who aren't part of
 the security team, and so far the security team seem to say it's not a
 concern for them, so for all I know it may just be theoretical…

Binary packages with the exact same version between etch and lenny:

$ zgrep -h Filename dists/{etch,lenny}/main/binary-i386/Packages.gz | sort | 
uniq -d | wc -l
1838
$

Source packages at the same version between etch and lenny (which may
include source packages that have been incremented only by a binNMU
version):

$ zgrep -h ' .*\.dsc' dists/{etch,lenny}/main/source/Sources.gz | sort | uniq 
-d | wc -l
1630
$

This represents roughly 10% of the binaries in main, and roughly 16% of the
sources.

$ for src in $(
   zgrep -h ' .*\.dsc' ../../dists/{etch,lenny}/main/source/Sources.gz |
   sort | uniq -d | sed -e's/.* //; s/_.*//'
  ); do
zcat dists/lenny/updates/main/source/Sources.gz |
grep-dctrl -FPackage -sPackage -X $src
  done
$

So no actual source packages that have had this problem for etch and lenny,
interestingly enough.

I thought there had been one in the sarge timeframe; but I'm not going to go
digging any farther to confirm this.  Yes, the problem is more or less
theoretical.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Lucas Nussbaum]

On 01/09/09 at 23:14 +0200, Julien Cristau wrote:
 On Tue, Sep  1, 2009 at 14:06:17 -0700, Steve Langasek wrote:
 
  On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
   On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
  
That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
3. etch is released with P 1.0-1.
4. A security bug is found in P.
  
   Does this actually happen?  How often?
  
  Often enough that it's been discussed repeatedly over the years; not often
  enough that anyone has fixed it. :)
  
 Every time I've seen it discussed, it was by people who aren't part of
 the security team, and so far the security team seem to say it's not a
 concern for them, so for all I know it may just be theoretical…

well, one nice feature is that it was only theoretical during the etch +
lenny release cycles, since +b  +etch  +lenny  +nmu.
So it is not surprising that it stayed unfixed for so long.

However, this was broken with sarge (+sarge  +etch), and is broken
with squeeze with NMUs:
1. Package P is available in testing with version 1.0-1
2. A security bug is found in P
3. A testing-security upload is made (1.0-1+squeeze1)
4. The bug is fixed in unstable in an NMU, also fixing other bugs
(1.0-1+nmu1)
5. The user installs 1.0-1+squeeze1
6. P 1.0-1+nmu1 migrates to testing
At this point, the user should install 1.0-1+nmu1 (it contains fixes to
other bugs) but will stay with 1.0-1+squeeze1.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Julien Cristau]

On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:

 That's unfortunate. Imagine the following scenario:
 1. Package P is released in sarge, with version 1.0-1.
 2. Package P is installed on a system S, running sarge.
 3. etch is released with P 1.0-1.
 4. A security bug is found in P.

Does this actually happen?  How often?

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Steve Langasek]

On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
 On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:

  That's unfortunate. Imagine the following scenario:
  1. Package P is released in sarge, with version 1.0-1.
  2. Package P is installed on a system S, running sarge.
  3. etch is released with P 1.0-1.
  4. A security bug is found in P.

 Does this actually happen?  How often?

Often enough that it's been discussed repeatedly over the years; not often
enough that anyone has fixed it. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Julien Cristau]

On Tue, Sep  1, 2009 at 14:06:17 -0700, Steve Langasek wrote:

 On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
  On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
 
   That's unfortunate. Imagine the following scenario:
   1. Package P is released in sarge, with version 1.0-1.
   2. Package P is installed on a system S, running sarge.
   3. etch is released with P 1.0-1.
   4. A security bug is found in P.
 
  Does this actually happen?  How often?
 
 Often enough that it's been discussed repeatedly over the years; not often
 enough that anyone has fixed it. :)
 
Every time I've seen it discussed, it was by people who aren't part of
the security team, and so far the security team seem to say it's not a
concern for them, so for all I know it may just be theoretical…

Cheers,
Julien



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Lucas Nussbaum]

On 26/08/09 at 23:29 -0500, Manoj Srivastava wrote:
 On Wed, Aug 26 2009, Steve Langasek wrote:
  On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
  Given that devscripts,  lintian,  and the dev-ref
   all advocate  or implement  +nmu\d+, and that debhelper and  cdbs look
   at the hyphen for determining native vs non-native,  I have tried to do
   so.  I think the proposed practice is strictly better  than not
   specifying any conventions, and where possible, Ihave tried to stick to
   best practices as documented in the dev-ref to base policy on.
 
  Having said that, there are a lot of packages that seem to still
   use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this
   policy change as a 'recommends', and letting lintian warn about the
   version number.
 
  I don't agree that this is something that should be recommended.
  Changing the convention for NMU versioning of non-native packages is
  not necessary in order to correct the use of confusing version numbers
  for NMUs of native packages.  If the dev-ref is recommending +nmuN for
  non-native packages, then I think that's a bug in the dev-ref - a
  common enough problem given the lack of a public process for dev-ref
  change reviews.
 
 I think they changed that in a newer release than the one
  referred to in the bug report I saw.

Yes. It was initially changed to +nmuN for both native and non-native
packages. But I recently saw that almost everybody was still using .N
for non-native ones, so I fixed dev-ref accordingly. (I don't think that
dev-ref should be used to change policy, it should document the current
pratice, which is +nmuN for native pkgs, and .N for non-native ones.)

 ,
 |  Stable Security NMU's
 |Version =~  m/\+deb\d\d.\d+$/
 |  Testing Security NMU's
 |   Version =~ m/\+debt\d\d.\d+$/
 `
 These last two do not have buy in from the security team, as far
  as I can tell.

That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
3. etch is released with P 1.0-1.
4. A security bug is found in P.
5. An oldstable security upload is done for P 1.0-1+sarge1
6. S installs 1.0-1+sarge1
7. A stable security upload is done for P 1.0-1+etch1
8. S is upgraded to etch. P isn't upgraded: 1.0-1+etch1  1.0-1+sarge1
9. sarge reaches end-of-life, and is no longer supported
10. Another security bug is found in P
11. A stable security upload is done for P: 1.0-1+etch2

At this point, S won't auto-upgrade to O 1.0-1+etch2 (since 1.0-1+etch2
 1.0-1+sarge1). S will keep the vulnerable version of P.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Steve Langasek]

On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
 Given that devscripts,  lintian,  and the dev-ref
  all advocate  or implement  +nmu\d+, and that debhelper and  cdbs look
  at the hyphen for determining native vs non-native,  I have tried to do
  so.  I think the proposed practice is strictly better  than not
  specifying any conventions, and where possible, Ihave tried to stick to
  best practices as documented in the dev-ref to base policy on.

 Having said that, there are a lot of packages that seem to still
  use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this
  policy change as a 'recommends', and letting lintian warn about the
  version number.

I don't agree that this is something that should be recommended.  Changing
the convention for NMU versioning of non-native packages is not necessary
in order to correct the use of confusing version numbers for NMUs of native
packages.  If the dev-ref is recommending +nmuN for non-native packages,
then I think that's a bug in the dev-ref - a common enough problem given the
lack of a public process for dev-ref change reviews.

Recommending use of +nmuN for native packages seems like an appropriate
thing for Policy to standardize, since using hyphens makes the package
versions appear non-native and appending .N to the version collides with
ordinary versioning conventions for native packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Steve Langasek]

On Tue, Aug 18, 2009 at 03:01:12PM -0500, Manoj Srivastava wrote:

  3) the developers reference also advocates adding +codename\d+. It
 also advocates using exactly the same tar.gz file as already in the
 archive.

 I propose that we carve out a version number space that reserves
  a suffix match of
  \+nmu\d+$
  for packages that are NMU's, and make this invariant for native and
  non-native packages.
 
1.0.1   -- 1.0.1+nmu1
1.0-1   -- 1.0-1+nmu1
 
 And NMU's can be distinguished by a simple regexp match.

 '-\d+\.\d+|\+nmu' is simple enough. :)

 --

 Similarly, for a recompilation or binary only NMU (common use
  case: outdated build environment, no source changes), the suffix can be
  \+b\d+$.
  This does require and modification of the changelog, so that the
  version number is changed (and thus the new package is used to upgrade
  the older, broken package).

a) the developers reference already advocates this
b) this is seen as a magic version number by the  archive maintenance
   tools, and the upload is not rejected for not having sources.
 
 1.0.1 -- 1.0.1+b1
 1.0-1 -- 1.0-1+b1

Because of the ties to the archive software, I think the binNMU convention
is appropriate to standardize in Policy.

 --

 A corresponding name space can be carved out for security
  uploads. Obviously a solution would be to add +debion.counter, where
  version should be anything that sorts correctly, such as the current
  stable version with something added if the upload is to testing.
  \+deb\d\d.\d+
  \+debt\d\d.\d+ (testing only, sorts ahead of stable)

  where
   1.0.1   --old-- 1.0.1+etch1 -- 1.0.1+deb40
   1.0-1   --old-- 1.0.1+etch1 -- 1.0-1+deb40

 (sarge -- deb31, etch --deb40, lenny -- deb50)

 In this case, binary only uploads sort below security uploads,
  but NMU's sort above security uploads.

This implies Policy leading implementation.  I don't think there's cause for
trying to standardize this namespace when this isn't the convention in use
today.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Manoj Srivastava]

On Wed, Aug 26 2009, Steve Langasek wrote:

 On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
 Given that devscripts,  lintian,  and the dev-ref
  all advocate  or implement  +nmu\d+, and that debhelper and  cdbs look
  at the hyphen for determining native vs non-native,  I have tried to do
  so.  I think the proposed practice is strictly better  than not
  specifying any conventions, and where possible, Ihave tried to stick to
  best practices as documented in the dev-ref to base policy on.

 Having said that, there are a lot of packages that seem to still
  use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this
  policy change as a 'recommends', and letting lintian warn about the
  version number.

 I don't agree that this is something that should be recommended.
 Changing the convention for NMU versioning of non-native packages is
 not necessary in order to correct the use of confusing version numbers
 for NMUs of native packages.  If the dev-ref is recommending +nmuN for
 non-native packages, then I think that's a bug in the dev-ref - a
 common enough problem given the lack of a public process for dev-ref
 change reviews.

I think they changed that in a newer release than the one
 referred to in the bug report I saw.

 Recommending use of +nmuN for native packages seems like an
 appropriate thing for Policy to standardize, since using hyphens makes
 the package versions appear non-native and appending .N to the
 version collides with ordinary versioning conventions for native
 packages.

So, we should have:

,
|  Format:
| Version:=  [epoch`:']upstream_version[`-'debian_revision]
|  Native Package NMU's:
| Version =~ m/\+nmu\d+$/
|  Binary Only NMU's:
|Version =~ m/\+b\d+$/
`

The next tgree are tentative:
,
|  Non-native package NMU:
|Version =~ m/\-\.\d+$/
`
This is tentative since I can't see why we need to outlaw
 packages adding \+nmu\d+ even on non-native packages. Perhaps policy
 should butt out here, if the pattern is different for non-native NMU's
 than for Native package NMU's.

,
|  Stable Security NMU's
|Version =~  m/\+deb\d\d.\d+$/
|  Testing Security NMU's
|   Version =~ m/\+debt\d\d.\d+$/
`
These last two do not have buy in from the security team, as far
 as I can tell.

How does that sound?

manoj
-- 
Most people's favorite way to end a game is by winning.
Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Manoj Srivastava]

On Thu, Aug 20 2009, Steffen Joeris wrote:


 I haven't followed all the discussion around this, so please excuse my 
 ignorance, but could someone try and explain to me in simple terms what we 
 are 
 trying to fix with all this policy stuff around versioning?
 I don't see why we have to replace our usual convention of:
 - Add a .X for normal NMUs (including security NMUs to 
 unstable/experimental)
 - Add +$codenameX  to uploads for oldstable/stable/testing (for security 
 and 
 non-security, regardless of whether NMU or MU)

 The only problem I could think of is when we start having a codename that 
 starts with a, since the binNMU convention is to add +bX.
 But I'd worry about that problem, when it arises (is there a toy story 
 character starting with a? :) ).

Well, it started with there being some confusion on what
 determining what was a native package, based on version numbers: and it
 turns out that while policy is clear about the distinction of an
 upstream version part and a Debian specific revision part (and,
 personally, it ought to follow that for a native package there is no
 Debian specific version, since it is all Debian specific), because of a
 practice some packages had of appending -0.1 for NMU's of native
 packages, making it impossible to tell if it was the NMU of a
 non-native package, or the NMU of a native package, without looking
 into the .dsc. This is unnecessarily hard, so some policy language
 carving out a name space for NMU's would be nice.

Then there as the issue of NMU vs codename specific NMU's (like
 security or backports), +codename\d might lexically sort before
 +conename++\d, if codename ++ sorts earlier. So coming up with +deb and
 +debt seems to stave off future issues with versions not sorting
 correctly.

This also makes new NMU's sort later than older codename
 specific uploads.

There is a preponderance of best practices already in play, and
 putting them into policy just gives them greater weight, and makes it
 possible for tools to depend on these naming rules.

The one issue I see is that +nmu\d is not common for non-native
 NMU's, though I think a consistent scheme is to be preferred, for ease
 of implementation in tools and grep-dctrl searches.

I am tempted to still recommend +nmu\d as the version suffix for
 any  NMU, end have lintian gently warn about it. My opinion is that it
 is regrettable if we went the route of the popular choice rather than
 the slightly better technical one, even if it is not the vogue; since I
 think that having a dependable, and simple, rule would be useful
 enough. Your mileage may vary.

I also understand that there are a myriad of choices we may make
 about naming, most of which are technically viable, but I think this is
 precisely the role for policy, to make a decision between several
 equally viable technical choices, if it helps integration and tools.

manoj
-- 
An ignorant man ages like an ox. His flesh may increase, but not his
understanding. 152
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Raphael Hertzog]

On Tue, 18 Aug 2009, Manoj Srivastava wrote:
 Additionally, 
   § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
 applicable 
   § C.1.1. `dpkg-source' states that it creates a diff.gz if
 appropriate, and looks at the diff.gz while extracting if
 applicable.

Heh, reading this remind me that policy should probably be updated to
reflect the new source package formats... (diff.gz can also be
debian.tar.ext, etc.)

 Given these, I read this as letting the tools rely on
  the following invariants, even though these are not explicitly spelled
  out in so many words in policy:
 
  1)  If there is a - in the version number, then the package is
  non-native
   a) the upstream version is the part of the string until the last
  '-' in the version number 
   b) there is a .orig.tar.gz and
   c) diff.gz referenced in the .dsc
  2) If there is no '-' in the version number, then the package is a
 debian native package
   a) there is no debian revision, all the version number is the
  upstream version number
   b) there is a tar.gz and no diff.gz in the .dsc file

There's no such invariant although it's a recommended practice:
http://lintian.debian.org/tags/native-package-with-dash-version.html

And the type of file associated is going to be different once the archive
accepts new source formats.

Format: 1.0 accepts either .tar.gz or (.diff.gz + orig.tar.gz)
Format: 3.0 (native) allows .tar.{gz,bz2,lzma}.
Format: 3.0 (quilt) allows debian.tar.{gz,bz2,lzma} +
orig.tar.{gz,bz2,lzma} + optionals orig-foo.tar.{gz,bz2,lzma}

dpkg-source doesn't impose any restriction on the package's version
when using any of those formats.

  1) dch --nmu adds +nmu1 for native packages
  2) +nmuX is already supported by devscripts and lintian.
  3) the developers reference also advocates adding +codename\d+. It
 also advocates using exactly the same tar.gz file as already in the
 archive.

While I would like us to standardize on +nmuX for all NMU, there's no general
consensus here. The developers-reference has changed again the recommendation
to match the dch --nmu practice:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532945

Now I believe that consistency here would be a win that is more important
than the ugliness or aesthetic problem that some DD seem to have with this
convention. I don't know if the discussion during the policy process can
lead to agreement on this.

 I propose that we carve out a version number space that reserves
  a suffix match of
  \+nmu\d+$
  for packages that are NMU's, and make this invariant for native and
  non-native packages.
 
1.0.1   -- 1.0.1+nmu1
1.0-1   -- 1.0-1+nmu1

And NMU of a new upstream version is 2.0-0+nmu1.

 Similarly, for a recompilation or binary only NMU (common use
  case: outdated build environment, no source changes), the suffix can be
  \+b\d+$.
  This does require and modification of the changelog, so that the
  version number is changed (and thus the new package is used to upgrade
  the older, broken package).

This suffix is enshrined in the dpkg tools because it knows to strip it
to generate the source:Version substvars. So it's definitely something
that can be standardized by the policy.

 A corresponding name space can be carved out for security
  uploads. Obviously a solution would be to add +debion.counter, where
  version should be anything that sorts correctly, such as the current
  stable version with something added if the upload is to testing.
  \+deb\d\d.\d+
  \+debt\d\d.\d+ (testing only, sorts ahead of stable)
 
  where
   1.0.1   --old-- 1.0.1+etch1 -- 1.0.1+deb40
   1.0-1   --old-- 1.0.1+etch1 -- 1.0-1+deb40
 
 (sarge -- deb31, etch --deb40, lenny -- deb50)

We had this discussion in the threads that discussed DEP1 on -project.
We did not reach a consensus (with the security team) here.

Subthread starting here:
http://lists.debian.org/debian-project/2008/08/msg00136.html
(Thijs is part of the security team)

But I also think that it would be nice to have a working long-term
solution and I would be in favor of such a scheme. The main objection was
that we do not know the next version in advance and the release team
has changed this fact, we already know that squeeze will be 6.0 and it
should stay the same in the future as the reasoning of this was to
facilitate the work of documentation writers.

 In this case, binary only uploads sort below security uploads,
  but NMU's sort above security uploads.
 
 This solves the use case:
   - The package version is 1.3 in all distributions.
   - A security issue is found.
   - 1.3+deb50 is uploaded to stable and testing.
   - The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable.
   - Some time passes, and the package is about to migrate to testing.
   - Migration works, because 1.3+nmu1  1.3+deb50.
 
 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Manoj Srivastava]

On Wed, Aug 19 2009, Raphael Hertzog wrote:

 On Tue, 18 Aug 2009, Manoj Srivastava wrote:
 Additionally, 
   § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
 applicable 
   § C.1.1. `dpkg-source' states that it creates a diff.gz if
 appropriate, and looks at the diff.gz while extracting if
 applicable.

 Heh, reading this remind me that policy should probably be updated to
 reflect the new source package formats... (diff.gz can also be
 debian.tar.ext, etc.)

I think appendix C is mostly stuff that is not normativce, and is
 only around until it can be incorporated into dpkg  documentation. If
 you think all the material in that appendix is currently available in
 dpkg, we can just drop appendix C from policy.


 Given these, I read this as letting the tools rely on
  the following invariants, even though these are not explicitly spelled
  out in so many words in policy:
 
  1)  If there is a - in the version number, then the package is
  non-native
   a) the upstream version is the part of the string until the last
  '-' in the version number 
   b) there is a .orig.tar.gz and
   c) diff.gz referenced in the .dsc
  2) If there is no '-' in the version number, then the package is a
 debian native package
   a) there is no debian revision, all the version number is the
  upstream version number
   b) there is a tar.gz and no diff.gz in the .dsc file

 There's no such invariant although it's a recommended practice:
 http://lintian.debian.org/tags/native-package-with-dash-version.html

That is correct.   (I thought that there would be other
 references in dev-ref or policy, but if there are I missed them, but
 you may add that if you have a '-' in the version number, debhelper
 seems to think it should not be native) 

This proposal is to take current best practice and move it into
 policy, since standardization here would help tools and users

 And the type of file associated is going to be different once the archive
 accepts new source formats.

 Format: 1.0 accepts either .tar.gz or (.diff.gz + orig.tar.gz)
 Format: 3.0 (native) allows .tar.{gz,bz2,lzma}.
 Format: 3.0 (quilt) allows debian.tar.{gz,bz2,lzma} +
 orig.tar.{gz,bz2,lzma} + optionals orig-foo.tar.{gz,bz2,lzma}

 dpkg-source doesn't impose any restriction on the package's version
 when using any of those formats.

OK. I was not planning on adding the above to policy anyway,
 just to express my understanding of the current state, but thanks for
 pointing out that the above understanding fails to take into account
 the new package format.

You are correct in that policy should not contain anything that
 goes against the new package formats.

  1) dch --nmu adds +nmu1 for native packages
  2) +nmuX is already supported by devscripts and lintian.
  3) the developers reference also advocates adding +codename\d+. It
 also advocates using exactly the same tar.gz file as already in the
 archive.

 While I would like us to standardize on +nmuX for all NMU, there's no
 general consensus here. The developers-reference has changed again the
 recommendation to match the dch --nmu practice:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532945

 Now I believe that consistency here would be a win that is more important
 than the ugliness or aesthetic problem that some DD seem to have with this
 convention. I don't know if the discussion during the policy process can
 lead to agreement on this.

This could be a problem.  I would prefer a succinct rule for the
 tools to rely on (even if it will take a while). Do you think if
 policy recommended \+nmu\d+  and lintian had a warning, this might
 change? Or should policy leave it alone?

 A corresponding name space can be carved out for security
  uploads. Obviously a solution would be to add +debion.counter, where
  version should be anything that sorts correctly, such as the current
  stable version with something added if the upload is to testing.
  \+deb\d\d.\d+
  \+debt\d\d.\d+ (testing only, sorts ahead of stable)
 
  where
   1.0.1   --old-- 1.0.1+etch1 -- 1.0.1+deb40
   1.0-1   --old-- 1.0.1+etch1 -- 1.0-1+deb40
 
 (sarge -- deb31, etch --deb40, lenny -- deb50)

 We had this discussion in the threads that discussed DEP1 on -project.
 We did not reach a consensus (with the security team) here.

 Subthread starting here:
 http://lists.debian.org/debian-project/2008/08/msg00136.html(Thijs is part of 
 the security team)

 But I also think that it would be nice to have a working long-term
 solution and I would be in favor of such a scheme. The main objection was
 that we do not know the next version in advance and the release team
 has changed this fact, we already know that squeeze will be 6.0 and it
 should stay the same in the future as the reasoning of this was to
 facilitate the work of 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Steffen Joeris]

Hi

  You can base security uploads on NMUs, so I think you could get
+deb50.1
+deb50.1+nmu1
+deb50.2
+deb50.2+nmu1
 
  Hum I understand +nmu1+deb50.1 for a security upload of a package whose
  last upload was an NMU, but I don't see in what occasions you would NMU a
  package in stable/testing (package in unstable don't have security
  uploads). And even if you did, I don't see why you keep the +deb50.1
  instead of simply replacing it with +nmu1.

 Yes, it was late when I wrote that. We cancertainly come up with
  a better progression example, if the rest of the proposal sounds good.
I haven't followed all the discussion around this, so please excuse my 
ignorance, but could someone try and explain to me in simple terms what we are 
trying to fix with all this policy stuff around versioning?
I don't see why we have to replace our usual convention of:
- Add a .X for normal NMUs (including security NMUs to 
unstable/experimental)
- Add +$codenameX  to uploads for oldstable/stable/testing (for security and 
non-security, regardless of whether NMU or MU)

The only problem I could think of is when we start having a codename that 
starts with a, since the binNMU convention is to add +bX.
But I'd worry about that problem, when it arises (is there a toy story 
character starting with a? :) ).

Cheers
Steffen



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Manoj Srivastava]

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
User: debian-pol...@packages.debian.org
Usertags: normative issue

Hi,

Currently, there is some ambiguity in the areas of version
 numbering, debian_revision, native packages, and requirement for a
 diff.gz/orig.tar.gz files in a source package. Also, currently policy
 does not carve out version name spaces for NMU's (native and non-native
 packages), for version numbers for binary only uploads, though there
 are well established practices for these use cases.

To recap, this is what is incontrovertibly stated in policy:

,[ §5.6.12:  `Version' ]
|   The format is:
|  [epoch`:']upstream_version[`-'debian_revision]
|   upstream_version
|  SNIP
|   The comparison behavior of the package management system with
|   respect to the upstream_version is described below.  The
|   upstream_version portion of the version number is mandatory.
| 
|   The upstream_version may contain only alphanumerics[1] and the
|   characters `.'  `+' `-' `:' `~' (full stop, plus, hyphen, colon,
|   tilde) and should start with a digit.  If there is no
|   debian_revision then hyphens are not allowed; if there is no
|   epoch then colons are not allowed.
| 
|  debian_revision
|   This part of the version number specifies the version of the
|   Debian package based on the upstream version.  It may contain
|   only alphanumerics and the characters `+' `.'  `~' (plus, full
|   stop, tilde) and is compared in the same way as the
|   upstream_version is.
| 
|   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 turned into a
|   Debian package, and so there is only one debianisation of it
|   and therefore no revision indication is required.
`

Additionally, 
  § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
applicable 
  § C.1.1. `dpkg-source' states that it creates a diff.gz if
appropriate, and looks at the diff.gz while extracting if
applicable.

,[ § C.3. Source packages as archives ]
|  Original source archive - `package_upstream-version.orig.tar.gz'
|   This is a compressed (with `gzip -9') `tar' file containing the
|   source code from the upstream authors of the program.
| 
|  Debianisation diff - `package_upstream_version-revision.diff.gz'
|   This is a unified context diff (`diff -u') giving the changes
|   which are required to turn the original source into the Debian
|   source.  These changes may only include editing and creating
|   plain files.  The permissions of files, the targets of symbolic
|   links and the characteristics of special files or pipes may not
|   be changed and no files may be removed or renamed.
| 
|   All the directories in the diff must exist, except the `debian'
|   sub-directory of the top of the source tree, which will be created
|   by `dpkg-source' if necessary when unpacking.
| 
|   The `dpkg-source' program will automatically make the
|   `debian/rules' file executable (see below).
| 
|  If there is no original source code - for example, if the package is
|  specially prepared for Debian or the Debian maintainer is the same as
|  the upstream maintainer - the format is slightly different: then there
|  is no diff, and the tar file is named `package_version.tar.gz', and
|  preferably contains a directory named `package-version'.
`


Given these, I read this as letting the tools rely on
 the following invariants, even though these are not explicitly spelled
 out in so many words in policy:

 1)  If there is a - in the version number, then the package is
 non-native
  a) the upstream version is the part of the string until the last
 '-' in the version number 
  b) there is a .orig.tar.gz and
  c) diff.gz referenced in the .dsc
 2) If there is no '-' in the version number, then the package is a
debian native package
  a) there is no debian revision, all the version number is the
 upstream version number
  b) there is a tar.gz and no diff.gz in the .dsc file

--
Given that, it would be nice we could carve out a space in the
 version numbering that would help  us distinguish NMU's and binary
 uploads.

 1) dch --nmu adds +nmu1 for native packages
 2) +nmuX is already supported by devscripts and lintian.
 3) the developers reference also advocates adding +codename\d+. It
also advocates using exactly the same tar.gz file as already in the
archive.
 4) this is how debhelper, cdbs, and my packaging scripts handle it.

Please also look at the discussion below, which led to
 

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Don Armstrong]

On Tue, 18 Aug 2009, Manoj Srivastava wrote:
 Given these, I read this as letting the tools rely on
  the following invariants, even though these are not explicitly spelled
  out in so many words in policy:
 
  1)  If there is a - in the version number, then the package is
  non-native
   a) the upstream version is the part of the string until the last
  '-' in the version number 
   b) there is a .orig.tar.gz and
   c) diff.gz referenced in the .dsc

  2) If there is no '-' in the version number, then the package is a
 debian native package
   a) there is no debian revision, all the version number is the
  upstream version number
   b) there is a tar.gz and no diff.gz in the .dsc file

(1) is not necessarily true in the case of NMUs of native packages.[1]
The only way to tell if a package is native or not is to inspect the
.dsc. [So long as the as-yet-to-be-proposed wording is clear on this,
it should be a big deal.]

That said, the rest looks reasonable, but it would probably be useful
to make sure that we're actually representing current practice.
  

Don Armstrong

1: I've personally made a at least one of these before I was aware of
the +nmu1 option.
-- 
Three little words. (In descending order of importance.)
I
love
you
 -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Manoj Srivastava]

On Tue, Aug 18 2009, Don Armstrong wrote:

 On Tue, 18 Aug 2009, Manoj Srivastava wrote:
 Given these, I read this as letting the tools rely on
  the following invariants, even though these are not explicitly spelled
  out in so many words in policy:
 
  1)  If there is a - in the version number, then the package is
  non-native
   a) the upstream version is the part of the string until the last
  '-' in the version number 
   b) there is a .orig.tar.gz and
   c) diff.gz referenced in the .dsc

  2) If there is no '-' in the version number, then the package is a
 debian native package
   a) there is no debian revision, all the version number is the
  upstream version number
   b) there is a tar.gz and no diff.gz in the .dsc file

 (1) is not necessarily true in the case of NMUs of native packages.[1]
 The only way to tell if a package is native or not is to inspect the
 .dsc. [So long as the as-yet-to-be-proposed wording is clear on this,
 it should be a big deal.]

I understand today that perhaps NMU's of native packages do not
 follow 1. However, consider this:

 1) dch --nmu adds +nmu1 for native packages
 2) +nmuX is already supported by devscripts and lintian.
 3) the developers reference also advocates adding +codename\d+. It
also advocates using exactly the same tar.gz file as already in the
archive.
 4) this is how debhelper, cdbs, and my packaging scripts handle it.
 
Please also look at the discussion below, which led to
 developers reference changing its recommendation.
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 

That link states that debhelper, cdbs, and (ahem) my scripts all
 use the same convention for distinguishing native packages from non
 native ones, namely, the presence of a hyphen in the version number. 

I am suggesting, in this case, we *make* policy to explicitly
 adopt the design that the dev-ref, devscripts, lintian, etc all
 currently espouse; with perhaps the proviso that this be a should or
 perhaps recommended bahaviour  for a while. I consider having to look
 into a .dsc file to see whether a package is a native NMU or a
 non-native package to be  a flaw large enough to warrant making policy
 here, especially since debhelper and cdbs and devscripts all follow
 this. 

As far as policy is concerned,  there is a strong indication
 that if there is a - in the version, there is an upstream package, and
 there is a debian revision, and there are also indications that a
 non-native package needs to have orig.tar.gz/diff.gz.

Making a package seem like it is native and non native based on
 whether the last upload was a NMU is bad, and it contradicts both policy
 on version number format and the def ref recommendations.

 That said, the rest looks reasonable, but it would probably be useful
 to make sure that we're actually representing current practice.

Given that devscripts, lintian, debhelper, cdbs and the dev-ref
 all advocate  or implement  +nmu\d+, I have tried to do so.


Having said that, there are a lot of packages that seem to still
 use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this
 policy change as a 'recommends', and letting lintian warn about the
 version number.

__ egrep '^Version: ' /var/lib/dpkg/available | wc -l
26797
__ egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/  
print' | wc -l
2127

Of course, the majority of these packages are not native
 packages, but it is hard to tell which are which.

manoj
-- 
Cynicism is an unpleasant way of saying the truth. Lillian Hellman
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Manoj Srivastava]

On Tue, Aug 18 2009, Don Armstrong wrote:

 On Tue, 18 Aug 2009, Manoj Srivastava wrote:
 Given these, I read this as letting the tools rely on
  the following invariants, even though these are not explicitly spelled
  out in so many words in policy:
 
  1)  If there is a - in the version number, then the package is
  non-native
   a) the upstream version is the part of the string until the last
  '-' in the version number 
   b) there is a .orig.tar.gz and
   c) diff.gz referenced in the .dsc

  2) If there is no '-' in the version number, then the package is a
 debian native package
   a) there is no debian revision, all the version number is the
  upstream version number
   b) there is a tar.gz and no diff.gz in the .dsc file

 (1) is not necessarily true in the case of NMUs of native packages.[1]
 The only way to tell if a package is native or not is to inspect the
 .dsc. [So long as the as-yet-to-be-proposed wording is clear on this,
 it should be a big deal.]

I understand today that perhaps NMU's of native packages do not
 follow 1. However, consider this:

 1) dch --nmu adds +nmu1 for native packages
 2) +nmuX is already supported by devscripts and lintian.
 3) the developers reference also advocates adding +codename\d+. It
also advocates using exactly the same tar.gz file as already in the
archive.
 4) this is how debhelper, cdbs, and my packaging scripts handle it.
 
Please also look at the discussion below, which led to
 developers reference changing its recommendation.
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437392 

That link states that debhelper, cdbs, and (ahem) my scripts all
 use the same convention for distinguishing native packages from non
 native ones, namely, the presence of a hyphen in the version number. 

I am suggesting, in this case, we *make* policy to explicitly
 adopt the design that the dev-ref, devscripts, lintian, etc all
 currently espouse; with perhaps the proviso that this be a should or
 perhaps recommended bahaviour  for a while. I consider having to look
 into a .dsc file to see whether a package is a native NMU or a
 non-native package to be  a flaw large enough to warrant making policy
 here, especially since debhelper and cdbs and devscripts all follow
 this. 

As far as policy is concerned,  there is a strong indication
 that if there is a - in the version, there is an upstream package, and
 there is a debian revision, and there are also indications that a
 non-native package needs to have orig.tar.gz/diff.gz.

Making a package seem like it is native and non native based on
 whether the last upload was a NMU is bad, and it contradicts both policy
 on version number format and the def ref recommendations.

 That said, the rest looks reasonable, but it would probably be useful
 to make sure that we're actually representing current practice.

Given that devscripts,  lintian,  and the dev-ref
 all advocate  or implement  +nmu\d+, and that debhelper and  cdbs look
 at the hyphen for determining native vs non-native,  I have tried to do
 so.  I think the proposed practice is strictly better  than not
 specifying any conventions, and where possible, Ihave tried to stick to
 best practices as documented in the dev-ref to base policy on.

Having said that, there are a lot of packages that seem to still
 use versions like m/\-\d+\.\d+$/, so perhaps we should be couching this
 policy change as a 'recommends', and letting lintian warn about the
 version number.

__ egrep '^Version: ' /var/lib/dpkg/available | wc -l
26797
__ egrep '^Version: ' /var/lib/dpkg/available | perl -nle 'm/\-\d+\.\d+$/  
print' | wc -l
2127

Of course, the majority of these packages are not native
 packages, but it is hard to tell which are which.

manoj
-- 
Cynicism is an unpleasant way of saying the truth. Lillian Hellman
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org