osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Inconsistencies in package versions for stable releases


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180706/225d61f5/attachment.sig>