On Sat, Jul 7, 2018 at 1:30 AM Tyler Hicks <firstname.lastname@example.org> wrote:
On 07/05/2018 11:15 PM, Simon Quigley wrote:
> 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 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  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  would fail to upgrade
dpkg --compare-versions 17.11.3-3 gt 17.11.3-3ubuntu0.18.04
- 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
- 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 ?
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
> Here are some uploads that I would have probably seen rejected depending
> on the SRU team member because of the version:
> 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 $?
> $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $?
> 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 lacking any important
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
> Can we adopt it as the uniform standard for updates in a
> stable release, or is there a good reason to continue with inconsistency
+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.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Software Engineer, Ubuntu Server