[SRU] Deb version numbering is misleading

[Nathan Teodosio]

[Impact]
For Ubuntu >= Focal the transitional debs are frozen at the version number 1:85...

This might make one think[1][2] that it will install a critically outdated Chromium while it does not, because it installs the snap.

[Test plan]

Install the package and confirm the version change with e.g.

  dpkg -l | grep '^ii *chromium-browser *2:1snap1-0ubuntu1'

[Regression potential]

If the version were incorrectly constructed the deb build could fail.

[1] https://answers.launchpad.net/ubuntu/+source/chromium-browser/+question/702591
[2] https://askubuntu.com/q/1420925

[Nathan Teodosio (nteodosio)]

I'm proposing changing the version number from 1:85.0.4183.83-0ubuntu3 to 2:1+snap, similar to what Firefox does.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "chromium.diff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Lukas Märdian (slyon)]

Thank you for this suggestion.
Even though bumping the epoch is a very big hammer, it sounds very sensible to me.
The patch is looking mostly good, too.

But I wonder if we should rather change the version number to "2:1snap1-0ubuntu1", in order to use a similar format as we have on Firefox (LP: #1892724)? What do you think?

[Nathan Teodosio (nteodosio)]

Hi Lukas, thanks for having a look!

> But I wonder if we should rather change the version number to
> "2:1snap1-0ubuntu1", in order to use a similar format as we have on
> Firefox (LP: #1892724)? What do you think?

So, my hunch reaction to that scheme is "god, are all those numbers
really meaningful and necessary?" Being this is a package that installs
a snap, with all the upstream and almost all downstream changes handled
in the snap, I couldn't think in a way we would benefit from more than
one "free" (i.e., not epoch) number, and that is why I suggested a
simpler scheme — just for the principle of parcimony's sake.

Now, there can definitely be shortsight from my side, as I'm usually
only bumping version numbers, not reworking or creating them. At any
rate, both schemes solve the problem of misleading users, and I'm glad
to change to either.

[Sebastien Bacher (seb128)]

One argument for having 'ubuntu' in the version usually is that it will prevent the autosync job to override the revision (in case Debian would also bump their epoch to 2 and have a version higher) but having the package added to the sync blocklist would achieve the same result. Either way seems fine to me, it's just a deb version which is something most users will not ever notice or care about (the current thunderbird SRU version In lunar for example is 1:115.3.1+build1-0ubuntu0.23.04.1... ;-)

[Nathan Teodosio (nteodosio)]

Thanks for the background, let's use 2:1snap1-0ubuntu1 then.

[Jeremy Bícha (jbicha)]

I have uploaded this and unsubscribed ubuntu-sponsors. Please feel free to resubscribe if you have anything else that needs to be sponsored.

[Launchpad Janitor (janitor)]

This bug was fixed in the package chromium-browser - 2:1snap1-0ubuntu1

---------------
chromium-browser (2:1snap1-0ubuntu1) noble; urgency=low

  * Modify the version scheme of the package (LP: #2007702). Epoch bumped to 2.
    Since this is a package that install the Chromium snap, there is no point in
    updating it just for the sake of the version number whenever there is a new
    Chromium release. On the other hand, we don't want to leave it stuck in a
    number such as 85 because it misleads users into believing the package will
    install Chromium 85, which would be severily outdated.

 -- Nathan Pratta Teodosio <email address hidden> Mon, 13 Nov 2023 10:20:10 +0100

[Athos Ribeiro (athos-ribeiro)]

Thanks, Nathan.

Would you mind filing the SRU paperwork as per the template at https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ?

I am unsure if this would be suitable for an SRU, but that's for the SRU team to assess and decide.

Moreover, I see that you are using the same version for all the proposed patches. If you check item 4.1 in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure, it states that, for SRUs, the version number should not conflict with any later and future version in other Ubuntu releases.

Could you please fix the version numbers for each release? Check the versions in jammy and focal for an example of how this could be done.

[Nathan Teodosio (nteodosio)]

Hi Athos, thanks for having a look.

 > Would you mind filing the SRU paperwork as per the template at
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ?

I think I have already done that. It is admittedly very short but so is
the proposed change. Should I extend any section?

 > Could you please fix the version numbers for each release?

I'm attaching those, thanks.

[Julian Andres Klode (juliank)]

2:1snap1-0ubuntu1.22.04.1 is a non-native version number but of course there is no upstream version, it would be a lot better to do this correctly as a native package, like 2:1snap0ubuntu1.22.04.1

[Nathan Teodosio (nteodosio)]

That scheme already made its way into Noble. Will we then [1] submit a new package with that native package scheme for Noble, [2] do the native package scheme only for the SRUs or [3] do the SRUs with the non-native scheme for consistency?

[Sergio Durigan Junior (sergiodj)]

While I see Julian's point, I believe it's better to stick to the same versioning scheme used in the Firefox deb, which is exactly what you did for Noble:

 firefox | 1:1snap1-0ubuntu2 | jammy | source, amd64, arm64, armhf
 firefox | 1:1snap1-0ubuntu3 | lunar | source, amd64, arm64, armhf
 firefox | 1:1snap1-0ubuntu3 | mantic | source, amd64, arm64, armhf
 firefox | 1:1snap1-0ubuntu3 | noble | source, amd64, arm64, armhf

As Athos said above, I'm not entirely sure how "SRU-able" this is, but either way, I went ahead and uploaded the debdiffs (after a minor typo fix).

I'm unsubscribing ubuntu-sponsors from this bug; feel free to resubscribe it if needed.

Thanks!

[Steve Langasek (vorlon)]

One of the possible impacts of bumping the version like this is that if a user has a local deb of chromium-browser installed that is higher than the current version, the new epoch will cause them to be upgraded to the transitional package that they had already opted out of.

This should be called out and the pros and cons weighed in the bug description ("Where problems can occur" / "Regression potential")

[Robie Basak (racb)]

Rejecting from the Unapproved queues as Steve's request above has not been addressed in over a month.