Call for testing: chromium-browser deb to snap transition

I truly get it, but i don’t think creating an update script that detects deprecated debs and reinstalls them as snaps is that hard to do. It’s still intrusive but it turns out to be much more coherent in a long term.

In this way, many users will get stuck with deb and snap installed. Deb package will show some info and snap will show another info. As it is today, not even the store is able to handle this situation because it doesn’t find chromium package. It’s so bizarre that if i install it and uninstall it via apt, without the snap pre-installed, it remains on my system as a snap, breaking the fundamental idea of managing packages using apt.

Imagine that a user installs it via Snap store and then, for some reason, also installs the deb package. If the user removes the deb package what will happen? And more important, what should happen? What if someone remove the snap and the deb remains, what will happen? Again, what should happen?

If a theme or extension is installed via apt and chromium is also installed via apt (but it is a snap), what will/should happen? Expanding this to more packages soon it becomes a completely broken system.

1 Like

The deb is a transitional package, removing it won’t affect the snap. That’s a well-defined behaviour. Note that the descriptions of the deb packages have been updated to make this clear:

$ apt-cache show chromium-browser | grep Description:
Description: Transitional package - chromium-browser -> chromium snap

In that case only the wrapper script (/usr/bin/chromium-browser) and a NoDisplay=true desktop file remain installed on disk, so they’re not visible to end users. The wrapper script, when executed, will detect that the snap is not installed and will inform the user that they need to install it. Again, that’s a well-defined behaviour.

1 Like

sudo apt remove chromium-browser for deb
sudo snap remove chromium for snaps

removing one, as far as I know doesn’t affect the other

That’s sudo apt remove chromium-browser for the deb, to be exact (the deb isn’t simply named “chromium” for historical reasons).

Thank you, I’ve updated my comment

There is game called Chromium, that’s probably why.

1 Like

Kubuntu 19.10
KDE Plasma 5.16.2

I don’t know if it’s a Chromium snap problem or a KDE task manager: I have Chromium pinned to the panel, lately with every chromium update, I can’t start it from the task manager anymore, I have to go to the> internet chromium menu, in this way yes starts.
If I put it back on the task manager, it works, until the next chromium snap update.

I wonder if the pinned launcher is pointing to the old one. Not sure how Snap update works, but I am thinking it might be something related to the pinned app pointing to an older reference.

I am not familiar with how pinning to the panel is implemented in KDE. A wild guess is that it includes the revision number of the snap in the path, which invalidates it at the next update. Editing the pinned entry to replace that revision number by “current” in the path should fix the problem.

Can anyone familiar with KDE’s internals point me to documentation / the code that implements pinning apps to the panel?

Exactly, if I put the mouse on the icon, the info is pointing to the connection of the old snap.

Here is my bad experience on Eoan 64 bits install with a gnome-shell on xorg session:

As you can see:

  • the problems are been seen with some package(s) upgrades but not with others (could it be related to gcc/python defaults upgrades ?)
  • losing saved passwords is also an issue.
  • logs are showing a few errors

Please do more tests across all flavours before using snap packaging as the only choice.

1 Like

Thank you for the feedback @9d9.

The issue you’re seeing with the app not launching is puzzling, and has not been reported anywhere else, as far as I know. Would you mind starting a new thread on the snapcraft forum to investigate that specific issue?

Regarding passwords, this is because the password-manager-service interface is not auto-connected. This is indeed bad user experience, and I am looking into options to solve this.

Please note that the candidate/from-source channel doesn’t exist anymore (the chromium snap is now always built from source), you should switch to the stable channel.

Comments about the passwords being lost when chromium has been broken:

  • when chromium is then loading again, the passwords are lost
  • so passwords are registered and saved again.
  • when chromium fails again (after some system packages upgrades (gcc/python/… ?), the newly saved passwords are again lost. That is strange as it seems passwords are saved outside the snap path. Not expected.

This looks related: https://bugs.kde.org/show_bug.cgi?id=402587

I reported the bug and they opened the phabricator issue.
https://phabricator.kde.org/D22506

Nice, thanks @emanuc!

again broken; get logged:

juil. 19 17:10:56 oem-desktop chromium_chromium.desktop[2022]: internal error, please report: running “chromium” failed: timeout waiting for snap system profiles to get updated

Thanks @9d9, that looks like a serious issue, I started a new thread on the snapcraft forum in the hope that snapd experts can shed some light on it.

Additional log from the last break above:

juil. 19 17:07:19 oem-desktop systemd[1]: snapd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
juil. 19 17:07:19 oem-desktop systemd[1]: snapd.service: Failed with result ‘exit-code’.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Service RestartSec=100ms expired, scheduling restart.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Scheduled restart job, restart counter is at 1.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Failed with result ‘exit-code’.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Service RestartSec=100ms expired, scheduling restart.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Scheduled restart job, restart counter is at 2.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Failed with result ‘exit-code’.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Service RestartSec=100ms expired, scheduling restart.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Scheduled restart job, restart counter is at 3.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Failed with result ‘exit-code’.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Service RestartSec=100ms expired, scheduling restart.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Scheduled restart job, restart counter is at 4.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Failed with result ‘exit-code’.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Service RestartSec=100ms expired, scheduling restart.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Scheduled restart job, restart counter is at 5.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Start request repeated too quickly.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Failed with result ‘exit-code’.
juil. 19 17:07:20 oem-desktop systemd[1]: snapd.service: Triggering OnFailure= dependencies.

  1. I was using ~/.chromium-browser.init to set force-device-scale-factor for chrome.
    CHROMIUM_FLAGS="–force-device-scale-factor=2 --new-window"
    How do I specify force-device-scale-factor for snap?

  2. I am running xubuntu eaon and chromium snap doesn’t know about password I saved before with package (in gnome keyring).

  3. Cursor in snapped chromium is very small.