It looks like Kubuntu 22.04 won't support the deb version of Firefox.

[SuperSapien64]

I just read that the deb to snap transition is scheduled to be completed in 22.04. So does this mean there will no longer be a .deb version of Firefox and Thunderbird in Kubuntu 22.04? Not even in the software center?

https://discourse.ubuntu.com/t/featu...-desktop/24210

[claydoh]

At this point, it will be like Chromium - the deb (if present) actually simply installs the Snap. No idea about Thunderbird., I have not looked.

Though, in this case Mozilla themselves are updating the Snap, instead of waiting on Ubuntu to do it. - this usually takes a few days
Kubuntu does not have anything to do with Firefox packaging/distribution.


We'll see in ~6 months if they can improve any speed/usage differences between a 'native' install.
Any theoretical space utilization differences should be easy to check - as FF is not relying much on any specific desktop toolkit, there shouldn't be much in the way of bloat, per se.

[Fred47]

"as FF is not relying much on any specific desktop toolkit" is not Firefox based on QTK2 while KDE is Qt? I know Kubuntu loads both so not an issue. This was an issue with my previous distro (Chakra) that was a pure KDE/Qt OS and we had to load QTK to run apps like Firefox and others.

[SuperSapien64]

At this point, it will be like Chromium - the deb (if present) actually simply installs the Snap. No idea about Thunderbird., I have not looked.

Though, in this case Mozilla themselves are updating the Snap, instead of waiting on Ubuntu to do it. - this usually takes a few days
Kubuntu does not have anything to do with Firefox packaging/distribution.


We'll see in ~6 months if they can improve any speed/usage differences between a 'native' install.
Any theoretical space utilization differences should be easy to check - as FF is not relying much on any specific desktop toolkit, there shouldn't be much in the way of bloat, per se.

So Kubuntu 22.04 should still have the .deb version of Firefox available as an option in the software center?

[claydoh]

Note I said "relying much"
it does not use much more than the file picker, a few gtk3 libraries. Not the whole of Gtk3 for sure.
Speed of use, and well fleshed integration will be the kicker, not likely disk space or duplication.

[Beerislife]

I remove Snap and Flatpak support as a matter of course. Will this change to Firefox packaging bother me? Not in the least, I'll just download the Linux tarball and extract it to /opt as I'm doing with Thunderbird 91 in KDE Neon.

[GreyGeek]

I remove Snap and Flatpak support as a matter of course. Will this change to Firefox packaging bother me? Not in the least, I'll just download the Linux tarball and extract it to /opt as I'm doing with Thunderbird 91 in KDE Neon.

So did I, about a year ago. Today, while exploring another issue, I noticed
libsnapd-glib.so.1
also known as libsnapd-glib1
IF you try to remove that it takes your entire plasma desktop with it. I having tried removing it sans dependencies, but if they put their "spyware" in that library it doesn't matter if you remove snapd or not.

[chimak111]

I remove Snap and Flatpak support as a matter of course. ...

How do you do so on KDE neon? In my brief use of KDE neon, I sent Flatpak to the trash via Discover's GUI as mentioned here. But I couldn't do the same for snap. So I ran sudo purge snapd but the next update (from 5.23.0 to 5.23.1) brought snapd back on my system but Flatpak support stayed trashed.

[Beerislife]

How do you do so on KDE neon? In my brief use of KDE neon, I sent Flatpak to the trash via Discover's GUI as mentioned here. But I couldn't do the same for snap. So I ran sudo purge snapd but the next update (from 5.23.0 to 5.23.1) brought snapd back on my system but Flatpak support stayed trashed.

Nothing special, I just removed everything related to snapd with Muon, except for libsnapd-glib.so.1, which takes a lot of stuff with it. Snapd hasn't come back for me.

[claydoh]

How do you do so on KDE neon? In my brief use of KDE neon, I sent Flatpak to the trash via Discover's GUI as mentioned here. But I couldn't do the same for snap. So I ran sudo purge snapd but the next update (from 5.23.0 to 5.23.1) brought snapd back on my system but Flatpak support stayed trashed.

plasma-discover-backend-snap iirc depends on snapd, with a similar package for flatpak. Remove those two plus snapd, then running an autoremove should get rid of all the pertinent bits.

[chimak111]

Okay! Will give it a go keeping an eye out for libsnapd-glib1 as mentioned by Beerislife.

So purging snapd made squashfs-tools "autoremovable" and purging plasma-discover-backend-snap made libsnapd-qt1 "autoremovable". Done. Now to wait for 5.23.3!

[verndog]

plasma-discover-backend-snap iirc depends on snapd, with a similar package for flatpak. Remove those two plus snapd, then running an autoremove should get rid of all the pertinent bits.

I have to remember this trick. Right now I'm on Ubuntu. Thanks!

[jglen490]

So I purge snapd and flatpak on any fresh install, as needed. All that's left on my system is the library file that GG mentioned, above. That library is of no consequence since it's purpose is "snapd-glib is a library to allow GLib based applications access to snapd, the daemon that controls Snaps." Since snapd does not exist, it doesn't matter if the library is called, it has nothing to do without the existence of snapd. I just verified that snapd has not been surreptitiously re-installed, and no snaps exist on my laptop.

Nothing to worry about.

[GreyGeek]

Okay! Will give it a go keeping an eye out for libsnapd-glib1 as mentioned by Beerislife.

So purging snapd made squashfs-tools "autoremovable" and purging plasma-discover-backend-snap made libsnapd-qt1 "autoremovable". Done. Now to wait for 5.23.3!

Interesting. Purging plasma-discover-back-end did not make make libsnapd-lib1 "autoremovable". So, I used

sudo dpkg -r --force-depends libsnapd-glib1

to remove it. Remove it it did. But, I was curious if the removal would stick. I did

sudo apt install -f

and sure enough, it wanted to raise libsnapd-glib1 from the dead, and, it suggested installing snapd as well. I am curious to see if the next time you do

sudo apt update && sudo apt full-upgrade

if that library sneaks back in.

If what jglen490 believes is true then leaving it installed is no risk, but I haven't looked at its source to see what it does.

EDIT:

$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
pulseaudio : Depends: libsnapd-glib1 (>= 1.49) but it is not installed
E:Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

[Don B. Cilly]

Actually, I really wonder what the big deal is, with snaps.
I did remove them from my previous system. Then, I did some tests. The conclusion of that discussion was, the two main gripes I had, namely messing up disk information and boot times, the first one was easy to fix, and the second one... just wasn't there. It really seems (see the last posts in the thread) that systemd-analyze does not tell anything like the truth on boot time, and snaps do not affect it. Not according to a stopwatch, they don't.

So I did not remove them from my present system, and have no problem with them.
Granted, I don't have a lot.

~$ snap list
Name Version Rev Tracking Publisher Notes
anbox 4-56c25f1 186 latest/beta morphis devmode
core 16-2.52.1 11993 latest/stable canonical✓ core