No more Flatpak (by default) in Ubuntu Flavors
Going forward, the Flatpak package as well as the packages to integrate Flatpak into the respective software center will no longer be installed by default in the next release due in April 2023, Lunar Lobster. Users who have used Flatpak will not be affected on upgrade, as flavors are including a special migration that takes this into account. Those who haven’t interacted with Flatpak will be presented with software from the Ubuntu repositories and the Snap Store.
Posted Feb 22, 2023 15:26 UTC (Wed)
by pbryan (guest, #3438)
[Link] (10 responses)
Posted Feb 23, 2023 7:34 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link] (8 responses)
Once you turn off the hyper-noisy default new-tab page it's actually quite good on tablets, especially with the sidebar + vertical tabs so most navigation and quick access is on the sides where you're already holding a tablet.
I still use Chrome on my desktops/laptops, but I've certainly found a niche where I prefer Edge even on Linux.
Posted Feb 23, 2023 13:41 UTC (Thu)
by pawel44 (guest, #162008)
[Link] (6 responses)
Posted Feb 23, 2023 21:58 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link] (4 responses)
A webkit-based browser is what >90% of the web is designed and tested on, for better or worse. And Chromium doesn't cut it for some sites that rely on the various 'magic sauce' components the binary browsers include.
Posted Feb 24, 2023 10:03 UTC (Fri)
by smcv (subscriber, #53363)
[Link]
Posted Feb 28, 2023 20:25 UTC (Tue)
by mrkernel (guest, #163905)
[Link] (2 responses)
Posted Mar 7, 2023 11:38 UTC (Tue)
by calumapplepie (guest, #143655)
[Link] (1 responses)
Posted Apr 20, 2023 11:51 UTC (Thu)
by Klavs (guest, #10563)
[Link]
Posted Feb 25, 2023 6:12 UTC (Sat)
by jmalcolm (subscriber, #8876)
[Link]
Personally I consider Google and Chrome a bigger issue than Microsoft these days. Other may not think that moving from Google to Microsoft product is much of an improvement but I have not used Chrome in years and want to keep it that way.
It is the same engine. I get that. As I said, my main browser is Firefox. The main reason for that though is that I use older hardware ( lowish amounts of RAM ) and I am terrible with tabs ( God knows how many I have open ) and Firefox just does better with that.
Posted Feb 28, 2023 18:09 UTC (Tue)
by ScottMinster (subscriber, #67541)
[Link]
Posted Feb 23, 2023 11:23 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link]
(These days I use Firefox by choice, rather than as a fallback.)
Posted Feb 22, 2023 17:12 UTC (Wed)
by tchernobog (guest, #73595)
[Link] (3 responses)
Plus, I personally find snaps very slow and poorly packaged compared to the corresponding flatpak alternatives. But that might just be me.
Of course, this is just "the default", you can still install flatpak. I just hope it stays that way.
Posted Feb 23, 2023 17:11 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link]
That situation with snaps reminds me the days I was still having a windows dual-boot 25 years ago, where you had to install random stuff you had no idea about, that stayed hidden somewhere on your machine and that you were never certain you would be able to completely uninstall.
I predict that it will be the next place where malware will install themselves. Who will remove vulnerable programs from there ? I'm seeing this number of suid root programs that anyone can abuse as a user:
$ sudo find /snap/ -perm -4000 |wc -l
Why do I need to have this live in parallel of the rest of the system ? Everyone will surely find it normal that there are 4 different "sudo" binaries on my system, three of which are there:
$ sudo find /snap/ -perm -4000 -name sudo -ls
$ sudo find /snap/ -perm -4000 -name sudo | xargs md5sum
Notice how one has been there for 2 years, not sure if it's vulnerable or not, but in any case it's easy to overlook.
If I were to install a rootkit on an Ubuntu machine, I would definitely install it into /snap so that it remains unnoticed for the longest possible time!
Posted Mar 2, 2023 10:52 UTC (Thu)
by davidgerard (guest, #100304)
[Link]
Posted Mar 3, 2023 20:10 UTC (Fri)
by jdulaney (subscriber, #83672)
[Link]
Posted Feb 22, 2023 18:58 UTC (Wed)
by atai (subscriber, #10977)
[Link] (5 responses)
Posted Feb 22, 2023 21:33 UTC (Wed)
by kilobyte (subscriber, #108024)
[Link] (3 responses)
Posted Feb 22, 2023 22:34 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Just in case, you missed it, the whole reason why Canonical dropped Flatpak is to focus on Snap and they ship Snap packages by default. So removing Snap is rather unlikely unless and until it completes fails.
Posted Feb 23, 2023 7:18 UTC (Thu)
by oldtomas (guest, #72579)
[Link]
I'm applying a mélange of Poe's Law and Hanlon's razor: "never attribute to stupidity what can be explained by irony".
That said, I concur in kilobyte's feelings. To put it in other words: "Oh, snap! No Flatpaks!". One reason more to steer clear of Ubuntu.
Posted Feb 23, 2023 11:59 UTC (Thu)
by gtirloni (subscriber, #85631)
[Link]
Snaps on the other hand are really complex and I had many issues with them, plus it requires a daemon, etc.
Posted Feb 22, 2023 23:28 UTC (Wed)
by jhoblitt (subscriber, #77733)
[Link]
Posted Feb 22, 2023 19:21 UTC (Wed)
by madscientist (subscriber, #16861)
[Link]
I have no problem using snap if it packages what I want: for example there's no snap for the latest GNOME Evolution so I install the flatpak and it works fine.
On the other hand, the flatpak version of Emacs is quite useless for me so I use the snap to get the latest version and it works great.
Posted Feb 22, 2023 19:40 UTC (Wed)
by dowdle (subscriber, #659)
[Link] (15 responses)
I don't really fault Ubuntu for removing flatpak by default and have to wonder why it was added in the first place. They have an agenda with the snap packaging system that they develop and promote... and like already mentioned, users can manually install flatpak easily if desired.
Posted Feb 23, 2023 1:02 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link] (14 responses)
So nobody bothers versus the wide-open nature (by comparison if nothing else) of Flatpaks.
Posted Feb 23, 2023 2:24 UTC (Thu)
by dowdle (subscriber, #659)
[Link] (9 responses)
Supposedly there is an open source implementation of the snap backend but it is not current compared to what Canonical is actually running. Not trying to be an apologist for Canonical, just trying to make sure the info is somewhat fair and balanced. :)
While flatpak is certainly more open, to the best of my knowledge, there isn't much adoption with regards to third-parties setting up their own flatpak repositories. Flathub appears to be the primary place... and I'm pretty sure it has some connection with Fedora and/or Red Hat... whether that be in hosting funding and/or packager pool. It is kinda hard to find specifics.
One key difference is that snaps also do cli packages and Flatpak is mainly for GUI applications only. I also heard that Canonical has replaced some system packages with snaps... so snap is basically a requirement on Ubuntu as well as distributions that derive from Ubuntu who don't put in how much ever effort is required to excise it out. Mint has taken that effort, after butting heads with Canonical a few times, but I'm not sure about the rest of the Ubuntu downstream.
Posted Feb 23, 2023 7:44 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link]
Most command-line and daemon software already packages and releases things as .deb's and .rpm's since that covers the majority out there so you're right, there hasn't been much move towards flats since it hasn't really been as useful.
Either solution is really just a workaround for the tried-and-true concept of backporting distro's in the end really, allowing some components to more readily be pushed to be fully updated without having to force-feed rolling-distro for the core system libraries and tooling.
Posted Feb 23, 2023 15:01 UTC (Thu)
by daniels (subscriber, #16193)
[Link]
As for the packager pool, all their repositories are hosted on GitHub, so you can easily go check who is listed as a maintainer, who contributes, etc. It's a pretty diverse bunch.
Posted Feb 24, 2023 12:59 UTC (Fri)
by hei8483j (guest, #124709)
[Link] (6 responses)
Posted Feb 24, 2023 15:04 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link] (5 responses)
flatpak is simply not aimed at and not suitable for CLI programs. And that's a crying shame.
For AppImages the situation is slightly different, though not really better: you can symlink an AppImage file to e.g. "amazingprogram". Then have your entrypoint application inside the AppImage call different programs depending on argv[0].
That's the one thing that snap does better: it allows for more than one binary in snaps & it can add those binaries (or wrappers to the correct snap invocation) to the usual paths.
Posted Feb 24, 2023 15:09 UTC (Fri)
by hei8483j (guest, #124709)
[Link] (4 responses)
Posted Feb 24, 2023 15:18 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link] (3 responses)
I'm not holding my breath for anything to change here.
Which makes me very, very sad as an application developer. There are now three cross-distro packaging formats, and all have severe limitations that they simply aren't willing to overcome! It seems not one of them wants to be _the_ universal, cross-platform, secure, easy-to-use (for the end user) format out there. They simply… don't want to be that. I guess I can respect an intentionally limited scope, but they had a real chance here and didn't take it. Now we're stuck with a solution that's barely good enough for barely most UI situations (flatpak) and that's available on mostly all UI environments/distros, and therefore people will have no more incentive to work on something better. We'll be stuck with this now for the next 20 years.
Posted Mar 6, 2023 13:57 UTC (Mon)
by ssokolow (guest, #94568)
[Link] (2 responses)
Posted Mar 6, 2023 15:43 UTC (Mon)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
Posted Mar 8, 2023 9:47 UTC (Wed)
by ssokolow (guest, #94568)
[Link]
Lines 154 through 173 and 283 through 328 began as a line or two of shell script that I rewrote in Python so I could massively improve performance by not forking a separate Lines 105 through 109 are an unfinished workaround for Flatpak not providing a way to expose multiple commands in the manifest metadata and, even if they did, mednaffe's maintainer probably not bothering to expose the bundled copy of mednafen. (I still need to come up with a proper implementation to match Flatpak-installed Lines 117 through 147 amd 214 through 250 are just an improved reimplementation of the code Flatpak already has for generating reverse-DNS command-line launch wrappers. (This script began as a middle finger to such a Tab-completion-hostile solution.)
Lines 188 through 211 are a workaround for the manifest not saying whether the command in the
Posted Feb 23, 2023 7:49 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
That is false. Debian has snaps. Not by default of course.
Posted Feb 23, 2023 9:57 UTC (Thu)
by jkingweb (subscriber, #113039)
[Link]
Posted Feb 23, 2023 13:19 UTC (Thu)
by atnot (subscriber, #124910)
[Link]
So while yes, it can run, there is clearly no sincere effort from Canonical to make it a first class citizen on non-ubuntu distributions.
Posted Feb 23, 2023 13:19 UTC (Thu)
by Conan_Kudo (subscriber, #103240)
[Link]
Posted Feb 22, 2023 22:55 UTC (Wed)
by himi (subscriber, #340)
[Link] (11 responses)
For some stuff I doubt that's much an issue - there's a whole bunch of things I'd consider fundamental tools that are now available as snaps, most of which will exist as short-lived processes where that issue is pretty minimal. But for something like a browser that's a major constraint - taking it down /before/ being able to even initiate the update, which is generally a sizable download, is just insane. If this is an architectural constraint with snaps then it's a massive indictment of the design; if it's just an implementation detail (which seems likely) then it's still a massive indictment of a system that seems to be considered "production ready".
If anyone knows of a way to fix this I'd greatly appreciate hearing about it (without just moving away from snap entirely, because I can't see how to do that with Firefox and it's probably not long-term viable other than moving to a different distro entirely, which is difficult for me due to work requirements).
Posted Feb 23, 2023 3:57 UTC (Thu)
by njs (subscriber, #40338)
[Link] (1 responses)
Random question: does anyone know whether flatpak solves this?
Posted Feb 23, 2023 6:37 UTC (Thu)
by tchernobog (guest, #73595)
[Link]
You might still get the "Your browser has been updated" message when opening a new tab, though, and need to reload it.
Posted Feb 23, 2023 4:24 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (6 responses)
With snap: it tells you there is an update ready. I can ignore it for days if I so choose. When I want to update I do "pkill -f firefox; sudo snap refresh" and restart firefox after it's done (a couple of minutes).
Personally it seems to me that the latter is less intrusive?
Posted Feb 23, 2023 6:25 UTC (Thu)
by himi (subscriber, #340)
[Link]
A rather more irritating scenario (which is irritatingly common for me) is where my laptop fails to resume from suspend and needs rebooting - with the package installation I'd generally have nothing extra to do in order to run the updated version, whereas with the snap I need to manually do the refresh before bringing up Firefox (and remember that the update is available before starting Firefox after the reboot). And this happens pretty regularly for me thanks to some dodgy hardware . . .
If the snap refresh could happen in the background I wouldn't care that much; even if it was only just downloading all the files it needed and /then/ telling me I needed to restart Firefox it'd be an improvement - it's not like this is rocket science, just download the new files to a temporary location in the background. And it should be possible to watch the mount point to see when I've shut down Firefox, so that it can automatically handle the refresh - download the update in the background, notify me that I need to restart Firefox because of an update, and trigger the final refresh once the old process is dead.
I can understand why they're pushing for snaps - it allows them to build one version of things like Firefox for all supported releases, which reduces their maintenance burden significantly. But it's so very klunky, for no real reason.
Posted Feb 24, 2023 9:39 UTC (Fri)
by madhatter (subscriber, #4665)
[Link] (4 responses)
Posted Feb 24, 2023 10:19 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
In theory, at least, container-based systems like Snap and Flatpak can download an update as a new container, and not remove the old version until the last instance of it has closed. This would be the best of both worlds - background update download as soon as the update is available, and only apply the update when you're ready to restart.
Posted Feb 24, 2023 16:09 UTC (Fri)
by smcv (subscriber, #53363)
[Link] (2 responses)
If you update a Flatpak app or runtime while the app is *not* running, then the old version will be cleaned up immediately (in the case of a runtime, this only happens if there is no running app that uses that runtime). If an instance of the app is running, it holds a lock which prevents that cleanup, but the "active" version swaps to the new one, so running another instance of the same app in parallel will give the new instance its updated /app and /usr. The old version will eventually be cleaned up, during the next update that takes place after the first instance has exited.
I don't know whether Snap does this. I would hope so, it's certainly in a position to use similar tricks if it wants to?
Of course, for particularly security-sensitive apps like Firefox, there's an incentive for the app to prompt you to exit and restart even if it's somewhat disruptive to do so, to make sure you're really running the updated version with its security fixes: there's a usability/security tradeoff here, and we can't realistically insert code changes into a running process, however important they might be.
Posted Feb 24, 2023 16:15 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
The reason I said "in theory" is that I've not tested Flatpak's behaviour. Snap currently requires you to close the app to update it - it won't download and install a newer version in parallel to the old version, and thus you have to quit your app, apply the update, and then restart.
I'm glad to hear that Flatpak does the right thing here - as a user, I want to be able to say "sure, get all the updates and install them" while I'm on mains power and reliable fast Internet, but I may not be able to restart the app to get the new version running until I've finished a chunk of work (which I may, in turn, not be able to do until I'm on a coach or train journey). The only thing you've not cleared up for me is whether it's easy, in the Flatpak world, to determine which apps I need to restart to update - it's obviously technically possible based on your description, but whether any of the front ends tell me "hey, you have Firefox 109 running, but the currently active version is 114.3 - restart Firefox to update" is a different question,
Posted Feb 24, 2023 21:27 UTC (Fri)
by himi (subscriber, #340)
[Link]
The usability/user-interaction question obviously has no clearly superior answer, and arguably would have different answers for different use cases (server versus desktop, system software versus end user, developer versus regular user, etc), but I think it's pretty hard to argue with implementing support for a "minimum downtime" approach that does as much as possible of the time consuming download and update in the background before requiring the running process to go away. Snap is definitely failing at that right now, for unknown reasons.
Posted Feb 23, 2023 12:59 UTC (Thu)
by dvandeun (guest, #24273)
[Link] (1 responses)
Posted Feb 23, 2023 20:42 UTC (Thu)
by himi (subscriber, #340)
[Link]
Posted Feb 23, 2023 2:01 UTC (Thu)
by pawel44 (guest, #162008)
[Link] (1 responses)
Posted Feb 23, 2023 7:52 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link]
This looks like a kernel bug to me.
Posted Feb 23, 2023 6:24 UTC (Thu)
by highvoltage (subscriber, #57465)
[Link]
Posted Feb 23, 2023 10:53 UTC (Thu)
by funderburg (guest, #3750)
[Link] (1 responses)
Posted Feb 23, 2023 18:11 UTC (Thu)
by smcv (subscriber, #53363)
[Link]
I realise some OSs only have a one-size-fits-all installation containing a full GUI environment, and encourage it to be installed on servers as well as on laptop/desktop/client machines, but I'd personally consider that to be a reason to choose a different OS for server use.
(disclosure: I'm an upstream co-maintainer of Flatpak, and it's installed on all my laptop/desktop/client machines but not on any of my servers)
Posted Feb 23, 2023 17:28 UTC (Thu)
by edwargix (guest, #136217)
[Link] (3 responses)
You need flatpak to install those, but maybe the installing flatpak itself part can be done automatically when Ubuntu sees .flatpakref file (JIT)?
Posted Feb 23, 2023 18:48 UTC (Thu)
by smcv (subscriber, #53363)
[Link] (2 responses)
GNOME Software and KDE's Plasma Discover each have a Flatpak plugin that makes them a suitable GUI for handling these files, and other desktop environments are welcome to develop something similar if they want to. The intention is that apps like those are the primary user-facing interface for installing and managing Flatpak apps: there is intentionally no GUI in Flatpak itself.
If you only have the flatpak(1) CLI, you can still use the URL of one of those files as a convenient command-line shorthand, but the CLI isn't an app with a .desktop file and so isn't in a position to be a reasonable MIME type handler. It's intended to be a combination of "behind the scenes implementation detail" and "advanced UI for command-line enthusiasts".
It would be fairly easy for Ubuntu developers to install a MIME handler for application/vnd.flatpak.ref that would install or run a suitable GUI on-demand, if they wanted to (but if they wanted to do this, they presumably would have done so already).
The "Ubuntu Software" package manager in Ubuntu 20.04 and older was a modified version of GNOME Software, but since 20.04 it was itself installed as a Snap app with the Flatpak plugin unavailable (and installing the Flatpak plugin via apt would result in having two very similar apps confusingly both identifying themselves as "Ubuntu Software", one Snap and one .deb, with installation of Flatpak apps only available through the .deb version, if I understand correctly). I'm not sure how this works in newer Ubuntu.
(disclosure: I'm a Flatpak upstream co-maintainer)
Posted Feb 23, 2023 20:04 UTC (Thu)
by edwargix (guest, #136217)
[Link] (1 responses)
Posted Feb 24, 2023 15:35 UTC (Fri)
by smcv (subscriber, #53363)
[Link]
(Actually, that's not quite all I can do: I'm also periodically updating Flatpak's semi-official PPA for Ubuntu. But as not-an-Ubuntu-user with various other responsibilities, I'm really not the best person to be doing that, so it would be great if someone closer to Ubuntu could help.)
In Debian, GNOME Software and Plasma Discover are installed by default by their respective desktop environments, and both have optional plugins/backends for Flatpak and Snap. GNOME Software has a Suggests (weak dependency) on its Flatpak and Snap plugins, while Plasma Discover only has a Suggests on its Flatpak backend (it does have a Snap backend, but presumably its maintainers are less happy with the maturity of that one or some similar factor).
Because these "app store" apps handle both apt and Flatpak/Snap packages, they would also be well-placed to install their own Flatpak and Snap backends via apt on a just-in-time basis when asked to install a .flatpakref file or a Snap equivalent, but I don't know whether they implement that.
Ever since Debian 11 switched to enabling unprivileged user namespaces by default, Flatpak's sandboxing in Debian has been as good as it is in any other distribution. As far as I know, Snap's sandboxing partially relies on AppArmor, making it incomplete in all non-Ubuntu-derived distributions: Debian is closer than most, because Debian at least uses AppArmor by default, but Debian's kernel doesn't have various extra AppArmor features which are specific to Ubuntu kernels and were never integrated upstream, notably control over access to AF_UNIX sockets.
Posted Feb 23, 2023 18:55 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (2 responses)
Naive question... what's wrong with AppIimage? I use a couple of programs that way (kdenlive, to take one major example) and they Just Work; no special software needed on my end.
Isn't that the goal of Snap and Flatpak too?
Posted Feb 23, 2023 19:44 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Posted Feb 23, 2023 21:09 UTC (Thu)
by dskoll (subscriber, #1630)
[Link]
Oh, I see. Yeah, I just download a new AppImage each time I want to update. For a handful of packages, that's fine, but it's not scalable across large numbers of packages or machines.
Posted Feb 24, 2023 14:08 UTC (Fri)
by callegar (guest, #16148)
[Link]
Also must say that as a kubuntu user, if I have to rely on self-contained applications, I find snap rather nasty and I tend to prefer other "fat" package formats. The fact that you cannot allow snaps to access anything that is yours but is mounted out of your home (there is no way to declare it, paths are hardwired in the code) is annoying and their suggestion that this is no issue because you can manually bind mount to your home or write a custom systemd unit for that shows a strange interpretation of user friendliness...
This seems to parallel a recent change by Microsoft to discourage the installation of Chrome to keep you using the Edge browser instead.
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
48
1946 146 -rwsr-xr-x 1 root root 149080 Jan 16 14:40 /snap/core18/2679/usr/bin/sudo
1946 146 -rwsr-xr-x 1 root root 149080 Jan 16 14:40 /snap/core18/2697/usr/bin/sudo
1107 163 -rwsr-xr-x 1 root root 166056 Jan 19 2021 /snap/core20/1778/usr/bin/sudo
1109 163 -rwsr-xr-x 1 root root 166056 Jan 16 13:06 /snap/core20/1822/usr/bin/sudo
06823865db45a2b00dac4da4efc9b6c0 /snap/core18/2679/usr/bin/sudo
06823865db45a2b00dac4da4efc9b6c0 /snap/core18/2697/usr/bin/sudo
eb8c10001fe28b9c4c2e42b96347f6db /snap/core20/1778/usr/bin/sudo
d08d4862398f26ed4e79a28035258450 /snap/core20/1822/usr/bin/sudo
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
And, in a depressingly typical Linux move, I've hacked up a workaround.
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
It's not as bad as it looks.
Lines 75 through 102, 112 through 115, and 253 to 280 are just a workaround for how so many Flatpak maintainers wind up naming the launchers/wrappers inside the container differently from the commands installed by the distro packages and may even use a generic name like "wrapper.sh". If they were instructed otherwise in the packaging guide, that'd be almost a fifth of the file made unnecessary.
No more Flatpak (by default) in Ubuntu Flavors
flatpak info -m subprocess for each package... so another near fifth is just boilerplate for "doing it properly" in a Python script that connects up to libflatpak rather than being a quick and dirty shell hack. (And some of it is reporting detected naming collisions or misconfigurations of the PATH.)
.desktop files to packages to identify which ones need CLI wrappers created for them.
command field expects paths or URLs as arguments.
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
Even Fedora has snaps available. And you can use snaps on RHEL/CentOS if you install the software from EPEL.
No more Flatpak (by default) in Ubuntu Flavors
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
Snap refresh behaviour is really strange.
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors
There are many security vulnerabilities discovered daily, lack of auto-update makes AppImage a non starter.
No more Flatpak (by default) in Ubuntu Flavors
No more Flatpak (by default) in Ubuntu Flavors