Inconsistencies in package versions for stable releases

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Inconsistencies in package versions for stable releases

Simon Quigley-2
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
[hidden email]
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Tyler Hicks-2
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
>
>
>



--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Lukasz Zemczak
In reply to this post by Simon Quigley-2
Just a few cents from me as an SRU member.

There is no 'inconsistencies' among the SRU team regarding versioning
as there is no 'standard' way of versioning packages. Rejection of a
package because of the versioning scheme, to me, is only a case of
preference and can vary between SRU members. There is no standard that
we're trying to force, and no SRU member should enforce that. We
*recommend* the security team's versioning scheme as it's the most
logical, but some of us also generally aim for consistency. So if a
package already used a different scheme for the selected series or
others, this is the way to go. Sometimes we accept a differently
versioned package as a 'one-time-off' (e.g. ubuntu-report), or
sometimes a package follows it's own, rather complicated, different
release model (e.g. snapd).

In my view the ubuntu-report scheme is the most invalid, but it has
been accepted conditionally as the package was not targeted for
backporting to anywhere else than bionic. I should have probably
rejected it and re-uploaded with a more fitting versioning applied, as
I did for a few others like this. But as I said, there generally is no
standard we *need* to enforce, so as long as the version works -
there's no requirement for rejection.

We should keep advertising the security team's versioning as the best
way to go, but right now - for what I can tell - there are no rules
for that.

Cheers,


On 6 July 2018 at 06:15, Simon Quigley <[hidden email]> 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.
>
> 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
> [hidden email]
> tsimonq2 on freenode and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>
>
> --
> ubuntu-devel mailing list
> [hidden email]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>



--
Łukasz 'sil2100' Zemczak
 Foundations Team
 [hidden email]
 www.canonical.com

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Simon Quigley-2
Hello Łukasz,

On 07/09/2018 02:32 AM, Lukasz Zemczak wrote:
> Just a few cents from me as an SRU member.

For the sake of clarity, are you representing yourself as an uploading
Ubuntu Developer, or the SRU team as a whole?

> There is no 'inconsistencies' among the SRU team regarding versioning
> as there is no 'standard' way of versioning packages.

Standards are not a prerequisite of inconsistency. If I complete a task
a different way than someone else does, and there's no written standard
way of completing this task, our actions are still not consistent.

> Rejection of a package because of the versioning scheme, to me, is
> only a case of preference and can vary between SRU members.

Right, this is the inconsistency I'm describing.

<snip />

> In my view the ubuntu-report scheme is the most invalid, but it has
> been accepted conditionally as the package was not targeted for
> backporting to anywhere else than bionic. I should have probably
> rejected it and re-uploaded with a more fitting versioning applied, as
> I did for a few others like this. But as I said, there generally is no
> standard we *need* to enforce, so as long as the version works -
> there's no requirement for rejection.

I think this is a slippery slope. There are a lot of versioning schemes
which *technically* work, but should we use them in practice?

For example, if I were to upload version
1.7.5-1bionicbeaveristhe1804ltsrelease.0.18.04.0.1 of a package which
has only been in Bionic and Cosmic, following this standard, as long as
it works, the SRU team would have to accept it.

> We should keep advertising the security team's versioning as the best
> way to go, but right now - for what I can tell - there are no rules
> for that.

My argument is that we *should* have rules here. If we say that the
security team versioning scheme should be followed, but if you don't
follow it and it still works anyway it'll still be accepted, then what's
the point of linking to the security team versioning scheme?

Thanks for your response.

--
Simon Quigley
[hidden email]
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Robie Basak-4
In reply to this post by Simon Quigley-2
Hi Simon,

On Thu, Jul 05, 2018 at 11:15:08PM -0500, 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.

Thank you for bringing this up.

Right now, though I prefer the security team's documented scheme, I
understand that this isn't fixed by any policy so I usually reluctantly
accept other schemes from uploaders unless I think there is some
specific issue with it.

However, I would like to see our project having more consistency on this
in the long term.

For example, onboarding new developers (whether colleagues of mine at
Canonical or other volunteers) is made more difficult for everyone if
things aren't consistent, because astute propsective developers should
be asking about inconsistencies and this wastes everyone's time. And
it's also painful to be a prospective developer if you repeat patterns
you see elsewhere but don't know what your sponsors will or won't
accept, and what the SRU team will or won't accept.

To this end, I'd like to see SRU policy move from "this team does it
well; you may want to do it like them" to "this is our recommendation"
to "this is a requirement and results in a reject unless you can justify
an exception".

However, I'm not sure we're ready to move hard on that yet. I'd like to
see better tooling first, so any change creates less friction in the
short term. I have plans about this.

In git ubuntu, we have the beginnings of a "lint" tool. I haven't worked
on it in a while and it needs major refactoring before continuing. I
don't recommend it for general use yet. But eventually I want to be able
to recommend it for use by uploaders and sponsorees, as well as have it
run in CI against the sponsorship queue (which I hope will use a
MP-based workflow by then).

Then I'd like the lint tool to simply be able to say "I was expecting
version string X for this that appears to be an SRU, but I see version
string Y instead".

At this stage I expect that I'll want to push for this kind of
consistency to become a recommendation and hopefully eventually policy
(except for edge cases and where an exception is justified).

This is my general answer for matters of upload consistency FWIW. I want
to get the lint tool to the stage that it is reasonably pluggable,
implement a check for any perceived inconsistency as a warning in the
tool, and then move towards recommendations and policy from there.

I'm not sure I'm in favour of policy changes in this consistency area
until we have the tooling, as I'm concerned it'll cause too much
friction in existing workflows (especially in the very long
upload/reject review cycle for SRUs we have at the moment). With the
tooling, I'm hoping to be able to close the reject delay by
short-circuiting it.

> 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.
I'm in favour of implementing a general and immediate ban on using
release codenames in version strings to prevent confusion. AFAIK,
release numbers can always be used in their place, and the pattern is so
rare (I didn't even know it was still done in the archive) that I think
it'd cause almost no pain to implement. It's a dangerous pattern because
it sets up an expectation that doesn't always hold, as you point out. I
think it's worth breaking the pattern in any package that already uses
it.

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

I prefer ubuntuX.Y instead of ubuntu(X+1) for SRUs as I think it's
helpful to make it obvious that it's an SRU and it avoids the necessity
to check that ubuntu(X+1) isn't already in use (which is error prone).
However I continue to reluctantly accept ubuntu(X+1) because it's a
pattern that so many developers seem to use. This is one that I want to
resolve in the long term by encouraging via a lint tool first before
turning it into a recommendation and eventually policy.

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

I'm in favour of turning it into a recommendation today. I thought it
already was, but I understand that some don't read the existing
documentation that way.

I don't want to mandate it until much further down the road though.

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Seth Arnold
On Tue, Jul 10, 2018 at 05:43:13PM +0100, Robie Basak wrote:
> pattern that so many developers seem to use. This is one that I want to
> resolve in the long term by encouraging via a lint tool first before
> turning it into a recommendation and eventually policy.

The Ubuntu security team has a shell-script function that helps us keep
the version strings consistent that may serve as a blueprint for such a
lint:

https://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/check-source-package#L623

Thanks

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Robie Basak-4
On Tue, Jul 10, 2018 at 12:37:33PM -0700, Seth Arnold wrote:
> The Ubuntu security team has a shell-script function that helps us keep
> the version strings consistent that may serve as a blueprint for such a
> lint:
>
> https://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/check-source-package#L623

Ah, thanks! FWIW, I wrote this a while ago for the lint:

https://git.launchpad.net/usd-importer/tree/gitubuntu/versioning.py#n356

The lint tool is mostly missing high level abstractions and tests at the
moment. Some of the core pieces are there already.

Robie

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistencies in package versions for stable releases

Christian Ehrhardt
In reply to this post by Tyler Hicks-2


On Sat, Jul 7, 2018 at 1:30 AM Tyler Hicks <[hidden email]> 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
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel