[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#852523: marked as done (Central section common to (old)stable and (old)stable-security regarding versioning recommendations)

Your message dated Sat, 5 Oct 2019 13:54:21 +0000
with message-id <20191005135421.xhsy5rkazg4iowy4@layer-acht.org>
and subject line re: #852523: devref: Central section common to (old)stable and (old)stable-security regarding versioning recommendations
has caused the Debian Bug report #852523,
regarding Central section common to (old)stable and (old)stable-security regarding versioning recommendations
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
852523: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852523
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: developers-reference
Version: 3.4.18

Hi

Since I failed to come up with a proper proposal for a formulation
let's open a bug for it. Part of the versioning recommendation is
already present in the developers-reference.

On Fri, Dec 02, 2016 at 08:57:14AM +0100, Emilio Pozuelo Monfort wrote:
> On 02/12/16 06:40, Salvatore Bonaccorso wrote:
> > Hi Emilio, Jonas, Antoine,
> > 
> > Thanks for all feedback.
> > 
> > On Thu, Dec 01, 2016 at 04:44:22PM +0100, Emilio Pozuelo Monfort wrote:
> >> 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.
> > 
> > Right it is spread around on various sections both for stable updates
> > and as well for security updates. Would it make sense to maybe add a
> > new section for handling versioning for (old)?stable(-securit)?
> > udpates, and then reference from both the security bug handling and
> > the stable-updates handling to it?
> 
> Yes, I think that would make sense.
> 
> > I do not have a wording right now for dev-ref, but I can look if I can
> > come up with something during the weekend (keep in mind though that it
> > will in any case need review, I'm not a native english speaker).
> 
> Great! I'm not a native speaker either, but I'll happy to look at it.
> 
> Maybe cc debian-release@ with the patch so the SRMs can look at it as well.
> 
> Cheers,
> Emilio

Emilio confirmed the current practice at as well from release team
point of view in:

https://lists.debian.org/debian-lts/2016/12/msg00013.html

It would be great if the version recommentations might be in some
central section wich could then be referenced from both stable- as
well security handling bugs sections.

Regards,
Salvatore

--- End Message ---
--- Begin Message --- 
version: 11.0.4
thanks

5.5.1 has been updated and now includes the release teams acceptence
criteria which has:

-  The proposed package must have a correct version number
   (e.g. ``...+deb10u1`` for ``buster`` or ``+deb9u1`` for ``stretch``)

ref:bug-security-building: also looks good to me:

-  Make sure the **version number** is proper. It must be greater than
   the current package, but less than package versions in later
   distributions. If in doubt, test it with ``dpkg
   --compare-versions``. Be careful not to re-use a version number that
   you have already used for a previous upload, or one that conflicts
   with a binNMU. The convention is to append ``+deb``\ *X*\ ``u1``
   (where *X* is the major release number), e.g.
   |version1-revision-deb-version-stable-u1|, of course increasing 1 for
   any subsequent uploads.

(both quotes from sources/pkgs.rst in git/unstable)

Thus I'm closing this bug. If you think that the notes for security
uploads should be updated further, please file a new bug (or if it's simple
we can also just fix it with a followup to this mail.)


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: