Thursday 5 July 2018

Inconsistencies in package versions for stable releases

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAls+7MwACgkQ4n8s+EWM
L6S1Uw//eZto0CR8xc1wRDsI/maXtioCaB56ghRqV5mTLxPv67C8jXuQjKg6PBlP
yQyYp2KbsyLCmF8ov68QfC1DuGmrZjCPqhRdlokVamNgsvoawc5VeypXcKWZtBb5
j/EvI6hVbds3JNfWIvclKheO4GzSQoaU2grLMzqHiHBqO8ueZjoaZFEQYi5gDbYl
cXyBVl2z29p+wCgn1J4bwxK32mOMGh5jCjSNbg4YPUL4A+kHgIOWDY2RUk1fkHR0
dC7nGA881znbProqD3qB+SNfAl4wb240OzZH09Es63aBnEJn/G9WyMycjXA0xLAY
MiXaHsZi9dAehXDYHj4J60UWyayx7LB/HdBfKl+nupz5Z0fG4buM/hpIPgqVUQ09
AqFtPK5vTPkt1R8/jsO2YM37EJzYVonlrdVb0iJDkrQwYx0BzUGn8mA1JcENteUR
mk05irmTgog5lp8sKV9zjYP3k59UN6MSygKnYdvg5Jebq3U9PFeBP/5HnHqGlN5F
4Pjr58wwsz+mSq+EP38yrD/F4OG2hd+afYPO2gmneySdCo3M5J+1RRqGL5PoXkvO
4Vl0a/rcIRsyAkkltOddPVtFNKuA6n+GEkPx04nN4azeycj0tIIDpPOCCkLlfB4q
CJwmWrHocJqCtFfijqdBROEVCDFT0VW4jJ6uZzSDBlkLH+41MSY=
=xgYO
-----END PGP SIGNATURE-----
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.

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? 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?

Thanks.

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

--
Simon Quigley
tsimonq2@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4