Bug#850729: debian-policy: Documenting special version number suffixes

[Russ Allbery]

Guillem Jover  writes:
> On Mon, 2017-01-09 at 11:39:01 -0800, Russ Allbery wrote:
>> Guillem Jover  writes:

>>> I've actually changed my mind over this one since seconding #542288,
>>> which I should probably unsecond. I think this is broken, and an NMU
>>> of a native packages should instead convert the packages to non-native
>>> and then use the normal non-native NMU versioning. See
>>>  and the
>>> surrounding sub-thread starting at
>>>  for my
>>> rationale.

>> I'd kind of like to keep the discussion of whether to convert native
>> packages to non-native when doing NMUs separate from the version
>> numbering convention if we can, since the latter is just a way of
>> documenting what people are actually doing currently (whether they
>> should do so or not).

> Fair enough. Consider my informal "unseconding" rescinded then. :) Also
> given that we already have such packages in the archive, even if we end
> up deciding to change the practice it might still be good to document
> it for historical reasons?

> I can file a separate bug report if you want? Or would you prefer
> discussion to take place beforehand?

I think a separate bug is fine -- we can start the discussion that way, in
the bug.  I think there was some previous debian-devel discussion of this,
but I don't think it reached any conclusion.

Thanks!

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

Bug#850729: debian-policy: Documenting special version number suffixes

[Guillem Jover]

Hi!

On Mon, 2017-01-09 at 11:39:01 -0800, Russ Allbery wrote:
> Guillem Jover  writes:
> > I've actually changed my mind over this one since seconding #542288,
> > which I should probably unsecond. I think this is broken, and an NMU
> > of a native packages should instead convert the packages to non-native
> > and then use the normal non-native NMU versioning. See
> >  and the
> > surrounding sub-thread starting at
> >  for my
> > rationale.
> 
> I'd kind of like to keep the discussion of whether to convert native
> packages to non-native when doing NMUs separate from the version numbering
> convention if we can, since the latter is just a way of documenting what
> people are actually doing currently (whether they should do so or not).

Fair enough. Consider my informal "unseconding" rescinded then. :) Also
given that we already have such packages in the archive, even if we end
up deciding to change the practice it might still be good to document
it for historical reasons?

I can file a separate bug report if you want? Or would you prefer
discussion to take place beforehand?

> I think my existing patch in #542288 gets most of this but not all of it.
> I forget why I didn't apply that in my current cleanup -- I think there
> were some open questions there, maybe about the native NMU thing?

I'd have to reread the patch. ;)

Thanks,
Guillem

Bug#850729: debian-policy: Documenting special version number suffixes

[Rene Engelhard]

On Mon, Jan 09, 2017 at 07:15:57PM +0100, Christoph Biedl wrote:
> ~deb+
>   Backport to the given (num1) distribution.
   ^^^
   bpo

Regards,

Rene

Bug#850729: debian-policy: Documenting special version number suffixes

[Christoph Biedl]

Guillem Jover wrote...

> I think this is actually #542288? But I'll let the editors decide.

It is. So much for the feeling "It was hard to believe nobody came up
with this beforehand". Also, there's quite a lot to read now.

> > +nmu Non-maintainer upload for native packages
> 
> I've actually changed my mind over this one since seconding #542288,
> which I should probably unsecond. I think this is broken, and an NMU
> of a native packages should instead convert the packages to non-native
> and then use the normal non-native NMU versioning. See
>  and the
> surrounding sub-thread starting at
>  for my
> rationale.

I'm not quite instantly convinced - but if you want to change the
practice of handling NMUs for native packages, that should be
discussed before continuing here. Also I'm not sure whether this is
the appropriate place, just one data point: I find it a bit confusing
NMU versioning is so different for native and non-native packages und
would appriciate a unification just for that purpose.

[ other forms ]

> This all pretty much describe current practice, so they seem fine.

Thanks. My intent was just to document that current practice.

Christoph


signature.asc
Description: Digital signature

Bug#850729: debian-policy: Documenting special version number suffixes

[Mattia Rizzolo]

On Mon, Jan 09, 2017 at 07:15:57PM +0100, Christoph Biedl wrote:
> ~deb+
>   Backport to the given (num1) distribution.

~deb+ is used for "backports" of something to stable through
point release or security, where that's more convenient than cherry
picking a patch and upload a +deb+.

Backports use ~bpo+ instead.

> Also, I wouldn't mind to document some suffixes used downstream,
> especially Ubuntu who have sometime "-u"-ish. But I'm not aware
> of their schema in the details.

'ubuntu' is the schema, to be appended to whatever debian version
that's based on (-0 is used as a revision if it's not coming from debian
but it's ubuntu only).   might be more convoluted than just an
unsigned integer for "stable uploads" and backports, for sorting and
clearity reasons (e.g. ubuntu16.04.2, that's the second (or third, if
you start counting from 0, afaik there is no rule here) revision of that
version uploaded directly to 16.04)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#850729: debian-policy: Documenting special version number suffixes

[Russ Allbery]

Control: severity -1 wishlist
Control: tags -1 patch
Control: merge -1 542288

Guillem Jover  writes:

> I think this is actually #542288? But I'll let the editors decide.

Yup, this is basically the same thing.

> I've actually changed my mind over this one since seconding #542288,
> which I should probably unsecond. I think this is broken, and an NMU
> of a native packages should instead convert the packages to non-native
> and then use the normal non-native NMU versioning. See
>  and the
> surrounding sub-thread starting at
>  for my
> rationale.

I'd kind of like to keep the discussion of whether to convert native
packages to non-native when doing NMUs separate from the version numbering
convention if we can, since the latter is just a way of documenting what
people are actually doing currently (whether they should do so or not).

I think my existing patch in #542288 gets most of this but not all of it.
I forget why I didn't apply that in my current cleanup -- I think there
were some open questions there, maybe about the native NMU thing?

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

Bug#850729: debian-policy: Documenting special version number suffixes

[Guillem Jover]

Hi!

On Mon, 2017-01-09 at 19:15:57 +0100, Christoph Biedl wrote:
> Package: debian-policy
> Severity: normal

> [
>   "version" is a horrible search term, hopefully I did not miss any
>   other report about this.
> ]

I think this is actually #542288? But I'll let the editors decide.

> Over time, several suffixes to version numbers have evolved to denote
> uploads outside the regular, incremental upload to unstable. In my
> opinion the policy should state these suffixes must not be used unless
> the particular condition is met, but are mandatory then. The main
> reason is several tools rely on these semantics and will likely result
> in unpredictable behaviour if the assumption does not hold.
> 
> So a proposal to add to "5.6.12 Version", perhaps as "5.6.12.1 Special
> suffixes to version numbers"
> 
> ==
> 
> There are several suffixes for special situations. Version numbers must
> end in the strings as below if and only if the given condition is met:
> 
> +nmu Non-maintainer upload for native packages

I've actually changed my mind over this one since seconding #542288,
which I should probably unsecond. I think this is broken, and an NMU
of a native packages should instead convert the packages to non-native
and then use the normal non-native NMU versioning. See
 and the
surrounding sub-thread starting at
 for my
rationale.

> .Non-maintainer upload for non-native packages
> +b   Binary NMU
> +debu
>   Update in the given (num1) stable distribution, through
>   a stable security or a point release update.
> +wheezy
>   Older form of the previous item.
> ~deb+
>   Backport to the given (num1) distribution.

This all pretty much describe current practice, so they seem fine.

> ==
> 
> The "+wheezy" may be removed after EOL wheezy plus a long grace
> period, so perhaps in 2020.
> 
> Also, I wouldn't mind to document some suffixes used downstream,
> especially Ubuntu who have sometime "-u"-ish. But I'm not aware
> of their schema in the details.

Thanks,
Guillem

Bug#850729: debian-policy: Documenting special version number suffixes

[Christoph Biedl]

Package: debian-policy
Severity: normal

[
  "version" is a horrible search term, hopefully I did not miss any
  other report about this.
]

Hello,

Over time, several suffixes to version numbers have evolved to denote
uploads outside the regular, incremental upload to unstable. In my
opinion the policy should state these suffixes must not be used unless
the particular condition is met, but are mandatory then. The main
reason is several tools rely on these semantics and will likely result
in unpredictable behaviour if the assumption does not hold.

So a proposal to add to "5.6.12 Version", perhaps as "5.6.12.1 Special
suffixes to version numbers"

==

There are several suffixes for special situations. Version numbers must
end in the strings as below if and only if the given condition is met:

+nmu Non-maintainer upload for native packages
.Non-maintainer upload for non-native packages
+b   Binary NMU
+debu
  Update in the given (num1) stable distribution, through
  a stable security or a point release update.
+wheezy
  Older form of the previous item.
~deb+
  Backport to the given (num1) distribution.

==

The "+wheezy" may be removed after EOL wheezy plus a long grace
period, so perhaps in 2020.

Also, I wouldn't mind to document some suffixes used downstream,
especially Ubuntu who have sometime "-u"-ish. But I'm not aware
of their schema in the details.

Regards,

Christoph


signature.asc
Description: Digital signature