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 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 > > >
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
