Inconsistencies in package versions for stable releases

Mon Jul 30 16:57:56 UTC 2018

On Sat, Jul 7, 2018 at 1:30 AM Tyler Hicks <tyhicks at canonical.com> wrote:

> On 07/05/2018 11:15 PM, Simon Quigley wrote:
> > Hello,
> >
> > This email is following several discussions I have had over the past few
> > weeks on how the versioning scheme of packages work with respect to
> > stable releases.
> >
> > It seems there is some inconsistencies with SRU team members accepting
> > different-versioned packages due to somewhat varied standards. Some
> > people say that the Security Team document on versions[1] is the
> > (lowercase c) canonical document on how things should be versioned,
> > while others just say "as long as the version isn't a problem."
> >
> > As someone who has had their packages rejected before because the
> > version did not match the former of the two preferences, I think it is
> > worth having a discussion on how we should do version numbers in a
> > uniform and agreed-on way.
>
> I would bet that you most likely had your -security uploads rejected due
> to the versioning not matching the Security Team scheme and not your
> -updates uploads. The Security Team is picky about versioning in
> -security (rightfully so, IMO).
>

I agree, we tend to follow the versioning scheme of [1] as well.
That said - as a side note to this discussion, I just found a case of
package versioning the page does not cover.

The reason mostly is that the security team does usually not care too much
about not yet released -dev.
At least I hit it because I eventually want -dev and last LTS to be the
same, but there could be cases this is even important for a security SRU.

Here is the situation:
- Package in the current development release will be or become a sync
like: 17.11.3-3
- Now we want to make last LTS the same, but the following based on [1]
would fail to upgrade
    dpkg --compare-versions 17.11.3-3 gt 17.11.3-3ubuntu0.18.04
   is false
- Obviously this would work:
    dpkg --compare-versions 17.11.3-3ubuntu0.18.04 gt 17.11.3-3ubuntu0.18.10
  But there should be no reason to force the version specific version in
-dev, it should be ok to just be a sync from Debian.
  After all - other than my case - one might realize later when 18.10 is
released and is on 17.11.3-3 that it is needed in Bionic
  Same situation, but no one would want to do a no-change rebuild SRU just
for the verison right?
- Instead in our discussion we thought that 17.11.3-3~ubuntu0.18.04 would
be the right version for this case.
  That would work for upgrades:
    dpkg --compare-versions 17.11.3-3 gt 17.11.3-3~ubuntu0.18.04

I wonder:
- are there drawbacks of this approach?
- if there are, how could we keep the version in -dev being a sync and do
better for the backport SRU?
- if the suggestion is good, should this case be added on [1]?

[1]: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation

> I try to be picky/consistent about it when sponsoring to -updates but
> what happens a lot of times is that the previous SRU for the given
> package used a more "lax" versioning scheme and the Security Team scheme
> isn't usable.
>
> > Here are some uploads that I would have probably seen rejected depending
> > on the SRU team member because of the version:
> > https://launchpad.net/ubuntu/+source/snapd/2.33.1+18.04ubuntu2
> > https://launchpad.net/ubuntu/+source/ubuntu-report/1.2.0~bionic
> > https://launchpad.net/ubuntu/+source/shim/13-0ubuntu2
> >
> > With snapd, it seems to be somewhat inverted from the typical case,
> > where Xenial gets the native package upload with no additions, Xenial+
> > gets +XX.YY, and Trusty- gets ~XX.YY.
> >
> > With ubuntu-report, I have always been discouraged from using codenames
> > in the version number, because if, for some reason, we needed this in
> > Xenial, being consistent with the naming scheme wouldn't work:
> >
> > $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~xenial"; echo $?
> > 1
> > $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $?
> > 0
> >
> > This means we would have to be inconsistent across releases.
> >
> > With shim, I have also been discouraged from doing ubuntuX, as opposed
> > to ubuntuX.Y. In this case, I would have gone with 13-0ubuntu0.2.
> >
> > My objective in pointing these out is not that these versioning schemes
> > do not work, or to pick on any one package or person. My point is, they
> > lack consistency with the rest of the archive, and some of these do not
> > work in other cases where a variable has changed. Most importantly
> > though, I have observed varied tolerance among the SRU team for these
> > version numbers.
> >
> > Is the existing document by the Security Team[1] lacking any important
> > considerations?
>
> The Security Team has had really good success with the documented
> versioning scheme. There are some minor corner cases where -security
> uploads have had to deviate slightly. I want to say that mostly had to
> do with "security fake syncs" where a Debian package is manually synced
> to -security. Maybe a current security team member has more recent
> memories than I do and can comment. OTOH, I'd say the scheme works %95
> of the time and the scheme can always be updated once the other 5% is
> identified.
>
> > Can we adopt it as the uniform standard for updates in a
> > stable release, or is there a good reason to continue with inconsistency
> > here?
>
> +1 from me for adopting it. I don't enjoy the inconsistency when I'm
> sponsoring uploads because I feel like I'm nitpicking about something
> that's not widely used/adopted.
>
> Tyler
>
> >
> > Thanks.
> >
> > [1]
> >
> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
> >
> >
> >
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180730/3c373db4/attachment.html>