Monday 30 July 2018

Re: Inconsistencies in package versions for stable releases



On Sat, Jul 7, 2018 at 1:30 AM Tyler Hicks <tyhicks@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]?

 
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@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd