Re: Versioning of new releases in (old)stable (Was: nss security update package ready for review)
On 01/12/16 16:25, Jonas Meurer wrote:
> Hi Security and LTS folks,
>
> Am 01.12.2016 um 15:54 schrieb Salvatore Bonaccorso:
>> On Wed, Nov 30, 2016 at 04:05:20PM -0500, Antoine Beaupré wrote:
>>> +nss (2:3.26.2-1+debu7u1) UNRELEASED; urgency=high
>>> +
>>> + * Non-maintainer upload by the LTS Security Team.
>>> + * New upstream release to fix CVE-2016-9074
>>
>> Depending on what is done this should be either 2:3.26.2-0+debu7u1 or
>> 2:3.26.2-1~debu7u1, but 2:3.26.2-1+debu7u1 is higher than 2:3.26.2-1.
>>
>> The former if you import new orig source on top of the previous
>> packaging to indicate the new import and have a version which is
>> before any possible such ones uploaded to unstable (which is even true
>> in this case because 2:3.26.2-1 is currently in unstable). The later
>> is often prefered if the package is mostly are build of :3.26.2-1 for
>> Wheezy. (The later proposed version works obviously as well in the
>> case of just a new upstream import, but Release team has often as well
>> done that distinction for the ~debXuY suffix).
>
> With this topic being discussed again and again recently, I suggest that
> we should agree on a defined standard regarding the versioning of new
> upstream releases uploaded to (old)?stable(-security)? and document it
> somewhere. What do you think?
>
> I don't have particular strong feelings on the exact versioning but I
> think that the following should be considered:
>
> *) New upstream releases in (old)?stable should use lover version
> numbers than their equivalent uploaded to unstable. This because
> packages uploaded to unstable are built using more recent versions
> of the build toolchain and libraries.
Moreover, New upstream releases should use lower versions than the next suite.
That means oldstable < stable < testing < sid. Not just oldstable < sid and
stable < sid, as you worded it.
That's why 2:3.26.2-1+debu7u1 would be bad even if unstable had 2:3.26.3-1 by
now, if stable had 2:3.26.2-1~debu8u1.
When doing an update in oldstable, we need to see if it has happened or is
happening in stable to avoid having a higher version in oldstable.
> *) The versioning should make it obvious whether the new release is
> based on a similar upload to unstable or whether it's packaged
> solely for (old)?stable.
>
> Consequently, the following (as already done for most uploads of new
> releases to (old)?stable) is my suggestion:
>
> *) Uploads of new upstream releases to (old)?stable that were packaged
> for unstable before should use the '~debXu1' suffix to the version
> number from unstable as they're basically backports of the package
> from unstable.
> *) Uploads of new upstream releases that were not packaged for unstable
> yet or will never be, should use the '1.2.3-0+debXu1' format (given
> that '1.2.3' is the upstream version.
That's the current practice, yes. As Salvatore pointed out, that's also what the
SRMs require for (old)stable uploads.
> If we can agree on this, what would be the proper place to document it
> for the future? Ideally, this should be mandatory for any uploads of new
> upstream releases to the (old)?stable suites, be it to
> (old)?stable-security, to stable-proposed-updates or to stable-updates.
Probably the developers-reference, which already mentions the +debXuY syntax in
various places (including the security updates section, 5.8.5.4 [1]), but
doesn't mention ~debXuY for the case of backports.
[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
Cheers,
Emilio
Reply to: