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.
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:
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.
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?
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.
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?
I am running xubuntu eaon and chromium snap doesn’t know about password I saved before with package (in gnome keyring).