You already posted that content in comment #26 there is no need to repeat the information
If you want to use Snaps, why don’t you install Snaps instead of installing a deb to install a Snap? What if the user don’t want to use this Snap? You have all the right to use Snap as default to most apps, and i thinks it’s a good idea, but use the Snap’s CLI and Store to do so and do not hijack apt/deb packages. It will only confuse users and break systems and distros.
1 Like
This is a transition from the deb to the snap. At some point in time the deb ceases to be supported, and its users need to be upgraded to the snap, as seamlessly as possible.
Of course new users are encouraged to install the snap directly, instead of the transitional deb wrapper.
Can you elaborate on breaking systems and distros?
As some users already stated there are yet several drawbacks in using Snaps (themes, extensions, init time, …). For instance, installing it on a system that doesn’t have snap pre-installed the icon will not appear in the menus right after installation is finished because snap path is not loaded yet. Trying to install a legacy version of the package is also not an easy task, because the packages names are the same, including dependencies. Apt/Debs installations may conflict with Snap installations, because now one is a dependency of another. It even takes out the opportunity of other distros build their own packages, because packages name are already taken.
Also, breaking a system doesn’t necessarily means breaking it completely, but if the user is used to do something and having a result, if he/she does the same in an updated system it is expected the same result. So, if chromium is installed using apt/deb is expected to work in a way but this is not true if instead a Snap is installed. Themes are the the easiest example to give, as you may see in the picture. I’ve test with several themes, including Arc and Numix that were installed via apt. Arc was the only one that worked, but even Adwaita didn’t work as expected.
Please rethink this idea of converting actual apt packages into snap wrappers. I know it makes sense for Canonical as a market move, but it’s totally against system’s transparecy, user freedom and project coherency, things that Canonical are known for. You should use Snap but please don’t mess up with apt repositories, just remove the packages and instruct people to use snaps or the store. Inexperienced users will probably use the Store anyway and advanced users will notice that the only available source is snap.
The reason is nor a ‘market’ move as you wrote but simply ensuring that users upgrading don’t get stucked in a old insecure version. If we were to remove the deb then an user upgrading to the next version of Ubuntu would end up with a chromium deb installed that would never get any update ever (since the archive wouldn’t have any new build for that package)…
2 Likes
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
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.