Flatpak 1.5 Released With Version Pinning, Self-Updates In Portals

[spstarr]

Most (often usually all) of your libraries will come from the runtimes, which you yourself don't manage and are supported by people who keep track of CVEs etc.

Except not if the developer is bundling their own libraries in the flatpak vs using flatpak runtimes (shared)... I would hope developers making flatpaks in whatever languages compile dynamically so they can use any flatpak runtimes - thereby absolving themselves of CVE nightmares, the distros manage the runtimes the developers just use the version(s) they need.

[Britoid]

At the expense of having other run times, which means more disk space consumption but these days I think that's less of an issue due to the size and cost of storage. I do wonder more about the security side of things. You're still 'bundling', even if you're leveraging someone else's bundles. Personally I don't think flatpaks come even close to being as good as RPM or DEB but I also think the use case is different.

Flatpaks de-duplication does quite well as minimizing disk space usage, e.g. for me the deduplication shrinks my /var/lib/flatpak folder from 32GB to 11GB. This may become more irrelevant as libraries on the host /usr can start to be removed.

Because of how the runtime system works, when the runtime get updated your application gets the updated library and Flatpaks serve a more specific purpose than rpms/debs and I think they're always going to stick around for system software, which Flatpak isn't designed to handle.

Honestly, is that really an advantage? These days, for the end user, launching of applications is abstracted away through the UI. It's not like you go trawling your file system to launch Firefox. For me a package manager is exactly what I want, tracking everything as it's far more powerful that just installing and uninstalling. Lack of good package management on other OS's like Windows and MacOS is what I miss.

Yes, it is being able to see how much storage an applications files and data are using. It's also a security thing, rpms/debs get root on install and can potentially install something malicious, not a flatpak. This is fine for system software, not for third-party desktop applications.

I'm struggling to make the connection there with roaming profiles.

You can decide not to keep everything in the home folder to sync app data.

Depends if you like JSON and YAML I guess. I actually find SPEC files easier to read but I guess it's mostly preference.

Agreed.

I'm not sure how that doesn't hold true for native package management?

See my first point. They also mean a dev hasn't got to package and test 5x.

This has not been my experience with flatpaks, almost the exact opposite - probably due to the sandboxing and isolation.

There's some software that do things in weird way (*cough* Chrome *cough*) that doesn't transfer very well. These problems will go after time as the software or Flatpak gets updated.

[Zoll]

Still no udev support, so that's a big no no for most IoT projects. SNAP is the only thing that works for such scenarios (besides regular debian packages that is).

[Oddsocks]

Because in most cases, native package managers install the dependencies in a monolithic way, causing apps to break completely on API breaks.
I couldn't run KDevelop anymore after updating it due to a missing newer version of libevent.

That sentence just doesn't compute. That's exactly what good package managers prevent and for the most part is entirely their point. The problems start when you use stuff outside the knowledge of the package manager. Of course it doesn't stop someone writing a garbage package. I've seen 'RPMs' before now that do nothing more than unpack a tarball all over your filesystem and bypass the entire point of using an RPM. Moronic to say the least. I don't actually dislike flatpaks per-se, I just think they compliment native packages but are not a good replacement for them.

This is my number one complaint with Flatpak. What if I don't want sandboxing?

Indeed.

[Oddsocks]

Because of how the runtime system works, when the runtime get updated your application gets the updated library and Flatpaks serve a more specific purpose than rpms/debs and I think they're always going to stick around for system software, which Flatpak isn't designed to handle.

Absolutely, which is why I think it's hard to say flatpaks are superior to native package management. It solves a superficially similar, but different problem.

Yes, it is being able to see how much storage an applications files and data are using. It's also a security thing, rpms/debs get root on install and can potentially install something malicious, not a flatpak. This is fine for system software, not for third-party desktop applications.

But you don't have to use flatpak to know that, but even so it's not a feature I find particularly compelling. Well firstly modern package managers use signed packages signed by your distro, so even if they install as root it really isn't a big deal. At some point you have to trust. That is no different for flatpaks. Secondly, let's be honest, root access is not required to install something malicious. Root access just provides more opportunity. It's perfectly possible for a flatpak to install something that runs as "you" and does something malicious.

[ssokolow]

But you don't have to use flatpak to know that, but even so it's not a feature I find particularly compelling. Well firstly modern package managers use signed packages signed by your distro, so even if they install as root it really isn't a big deal. At some point you have to trust. That is no different for flatpaks. Secondly, let's be honest, root access is not required to install something malicious. Root access just provides more opportunity. It's perfectly possible for a flatpak to install something that runs as "you" and does something malicious.

The problem is that you see a lot of people using third-party package sources (eg. PPAs) because the official repositories don't have what they want. Flatpak is designed to address that user behaviour.

As for installing malicious things, that's what the sandboxing is the basis for combatting. Bear in mind that Flatpak is being implemented incrementally, with each phase increasing the sphere of viable use cases. "GUI where the user can see which permissions are requested and refuse the package" is a later-stage feature because the first stage was to stabilize the standard, the second was to stabilize the command-line tooling and core libraries, and the third is to build out the GUIs.

(In fact, it'd probably be more accurate to say that the third stage is to build out the portal hosts and the fourth stage is to build out the GUIs surrounding installation.)

The purpose of the sandboxing is to make it possible to trust that the package can only do what it says on the can, as necessarily vague as that may be when generated from a sandbox manifest. (It also acts as an incentive for upstream developers to design to sandbox nicely, since it'll result in a friendlier-looking manifest readout.)

[tildearrow]

That sentence just doesn't compute. That's exactly what good package managers prevent and for the most part is entirely their point. The problems start when you use stuff outside the knowledge of the package manager..

...which is why in my opinion the package manager should be used only to install "system" libraries. The rest can be done through Flatpak, AppImage, Snap or a custom bundling solution.

[Oddsocks]

...which is why in my opinion the package manager should be used only to install "system" libraries. The rest can be done through Flatpak, AppImage, Snap or a custom bundling solution.

If a user is going to install something from a tarball, they'll do it regardless of Flatpak. Most users go outside the distro's packaging system when want they want is not available. Unless there's a Flatpak for every version of every piece of software then Flatpak doesn't solve this 'problem' either.

[Oddsocks]

The problem is that you see a lot of people using third-party package sources (eg. PPAs) because the official repositories don't have what they want. Flatpak is designed to address that user behaviour.

OK, so we're solving the issue of using 3rd party repositories by using a 3rd party repository? You don't see the irony? Secondly, unless all possible software is available as a Flatpak, it does not solve that "issue" either.

As for installing malicious things, that's what the sandboxing is the basis for combatting.

Combat, yes. Prevent no (which was implied with the original poster). Same as signed packages.

The purpose of the sandboxing is to make it possible to trust that the package can only do what it says on the can, as necessarily vague as that may be when generated from a sandbox manifest. (It also acts as an incentive for upstream developers to design to sandbox nicely, since it'll result in a friendlier-looking manifest readout.)

Yes, I think that was covered when I said at "some point you have to trust". Same as signed packages.

[ssokolow]

OK, so we're solving the issue of using 3rd party repositories by using a 3rd party repository? You don't see the irony? Secondly, unless all possible software is available as a Flatpak, it does not solve that "issue" either.

Flatpak's rationale is that the last couple of decades have shown that there's no practical way to stop people from wanting to enable third party repositories, so, instead, let's provide a new way to do them which can sandbox them to reduce the attack surface, provide the infrastructure for reliably accurate permissions prompts, and is reliably portable enough to attract developers to use it rather than the other options.

Each package installed via Flatpak is one less package installed through a system without native sandboxing.