You can now support the Flatpak package format on Open Collective

I have some of my opinion to share as I have create some Flatpak packages and submit to Flathub and also maintain some packages on openSUSE.

Package Flatpak app once and distribute to any distro is the best thing ever. This avoid duplication of effort. Not even openSUSE and Fedora can share the same spec file (a file that contain build instructions) since they some time use difference RPM macros. Maintaining a package across many distros are very tedious.

I also like the fact that Flatpak apps don't need root permission to install. Very convenient.

Apps that have long list of dependencies are less likely to break. On Flatpak, I or the upstream dev can choose deps version that work well. Sure that it is possible to patch the package to fix it, but things get hard and tedious as there are more packages.


Also response to Flatkill.
https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html

Quoting: WorMzylol, I've never seen rpm/deb described as 'next-generation'. I can kind of see it with rpm, but deb is something that deserves to be consigned to history as a terrible mistake that future generations should learn from.

IMHO, it's far better than what the 90% of desktops OS does. And even Microsoft found out, so they're working on a package manager lately...

Quoting: superboybotI think Flatpak is fine (and to a lesser extent Snap, especially on distros that include it by default), but I don't really see the point unless it offers a package that isn't in your repo. AppImage is cool though, as a preservation method.

But other than that, what problem is it solving? It seems that some people use them for many (most?) installed packages. I find it a bit strange. For instance, why is Firefox even offered on Flathub? Are there distros that don't have Firefox in the repositories?

For background, I am currently using Open Suse at work for software development, but have always returned to Windows on private devices due to a variety of annoyances any time I've used Linux.

One of them, and the only one that really applies for desktop PCs, is software distribution. Linux works pretty great, if all you need is in the repository. Until it isn't.

The most common case for me is needing one or two graphical programs in the most recent version due to a bug fix I need, so it doesn't help me that there is a package in the repository. I could use a rolling-release OS, but at work that might not be my choice, and even then I would sacrifice stability of the day-to-day work environment because I need one package to be more up-to-date.

Even if things are in the repository, I've found that sometimes they are just configured questionably. For instance with LyX, font packages were listed as "optional" dependencies, when their absence would actually, without any warning, cause weird glitches at runtime.

DEB/RPM Packages, if available, may be broken or at least incomplete for any given configuration. Often the only officially supported Linux is Ubuntu, on OpenSuse I often have to install things more manually, or fix things afterwards.

Additionally, adding non-repostitory software to the system has its risk. Installing OnlyOffice from a package left me with .so files that suddenly interfered with the build-and-run process.

By contrast, I'm never seeing similar issues on Windows. Software comes prepackaged as an installer, and the installer contains everything that's needed. (But sadly, Windows installers integrate Software too deeply into the system for my tastes.)

From a software developer view, these issues translate into supporting not "Windows and Linux" but "Windows and Ubuntu and OpenSuse and Arch and Debian and ...". From a distribution view, it means you need someone to support every little program you want running on your environment for your specific distribution, whether it is the company behind the software or a maintainer. Even Linus Torvalds complains about that.

As I understand, the application package formats try to solve these issues; Create a single package, and the package should be portable across all Linux systems, at least those running on compatible hardware architectures.

If desktop Linux is ever to compete with the install base of Windows, it needs to provide the conveniences that Windows-users take for granted.

The other part (mostly relevant for corporate environments) is that a natively or indistinguishable-from-native running version of Microsoft Office releases from the last ten years isn't optional. I tried with OnlyOffice and LibreOffice, but the moment your working with a customer who uses Microsoft Office, you will need it somehow, or the customer will be annoyed at you for breaking their documents; The only solution working properly here is a virtual machine with Windows and native MS Office.

Quoting: superboybotI think Flatpak is fine (and to a lesser extent Snap, especially on distros that include it by default), but I don't really see the point unless it offers a package that isn't in your repo. AppImage is cool though, as a preservation method.

But other than that, what problem is it solving? It seems that some people use them for many (most?) installed packages. I find it a bit strange. For instance, why is Firefox even offered on Flathub? Are there distros that don't have Firefox in the repositories?

I'm personally running an ostree distribution, which discourages users to install anything by package manager that is outside the standard ostree image. The reason is that only the ostree is tested and works, but any package layered on top of it could cause potential issues. On the other hand it allows you to easily rollback any update and the updates are atomic, so you don't need to worry about package database corruption during update. This is really a newbie friendly distribution, although it's still in development and not everything is working as it should.

In this kind of distribution the Flatpak or similar solution is a must. The Flatpak in advance has sandboxing (although it's on the packager to set it correctly). For example I'm running Steam in Flatpak and it doesn't have access to anything outside the flatpak container it's running in (except for few media folders in home), so any game that has some tracking things inside is not allowed to get any info about what you do outside of Steam, even what operation system are you running. You can easily change those permissions by FlatSeal application, which is also flatpak.

And as Klaus above me wrote, the Flatpak solves the issue of too much different distributions by creating a unified way that works on any distro that has flatpak available.


Last edited by Zlopez on 30 July 2021 at 9:55 am UTC

Quoting: ZlopezThe Flatpak in advance has sandboxing (although it's on the packager to set it correctly). For example I'm running Steam in Flatpak and it doesn't have access to anything outside the flatpak container it's running in (except for few media folders in home), so any game that has some tracking things inside is not allowed to get any info about what you do outside of Steam, even what operation system are you running. You can easily change those permissions by FlatSeal application, which is also flatpak.

I can appreciate the advantages of this kind of sandboxing/isolation, but I want my software to be more interconnected, not less. For example, not long after I first switched to Linux, I installed some Snap packages. Later, I tried writing a script that, among other things, ran one of these packages using certain parameters. Trying to find the binary was a bit of a nightmare; it was obfuscated behind multiple folders and symlinks. If it had acted like any other package on the system, designed to play nicely with everything else, it would have been more user-friendly from my perspective.

Quoting: KlausFrom a software developer view, these issues translate into supporting not "Windows and Linux" but "Windows and Ubuntu and OpenSuse and Arch and Debian and ...". From a distribution view, it means you need someone to support every little program you want running on your environment for your specific distribution, whether it is the company behind the software or a maintainer. Even Linus Torvalds complains about that.

As I understand, the application package formats try to solve these issues; Create a single package, and the package should be portable across all Linux systems, at least those running on compatible hardware architectures.

If desktop Linux is ever to compete with the install base of Windows, it needs to provide the conveniences that Windows-users take for granted.

I understand the benefits from a development/distribution point of view, but that doesn't necessarily translate into utility or necessity from a user's perspective. I think there are situations where Flatpaks are the obvious choice, but in my opinion, that is much more the case when using a non-Arch-based distro.

Quoting: superboybotI can appreciate the advantages of this kind of sandboxing/isolation, but I want my software to be more interconnected, not less. For example, not long after I first switched to Linux, I installed some Snap packages. Later, I tried writing a script that, among other things, ran one of these packages using certain parameters. Trying to find the binary was a bit of a nightmare; it was obfuscated behind multiple folders and symlinks. If it had acted like any other package on the system, designed to play nicely with everything else, it would have been more user-friendly from my perspective.

I can relate to that. Microsoft introduced exactly that issue with its UWP apps. Forget about modding games...

With Flatpak I can't tell for lack of experience. But you'd assume that all programs would expose at least a "run program" shell interface to the system. And if they include multiple shell utilities, preferably all of them.

The existence of those shell interfaces is one of the major advantages I see in Linux software over Windows software, which is often "GUI only" or supplying very awkward command line interfaces. E.g. SpiderOak One, where the program is (at least on Windows) always run asynchronously, and command line tools cannot be invoked while the GUI is running.

It does however not invalidate the utility of the packaging format; It just means that there is an important aspect that hasn't been considered sufficiently. From what you tell, they apparently over-do the abstracting-away part of the package. That's also not exactly helpful for when you want to provide a useful bugreport...

Quoting: superboybotI think Flatpak is fine (and to a lesser extent Snap, especially on distros that include it by default), but I don't really see the point unless it offers a package that isn't in your repo. AppImage is cool though, as a preservation method.

But other than that, what problem is it solving? It seems that some people use them for many (most?) installed packages. I find it a bit strange. For instance, why is Firefox even offered on Flathub? Are there distros that don't have Firefox in the repositories?

It is important to keep in mind that there are two separate use cases here.

1) There is the OS level. We are talking about kernels, system libraries, graphics drivers, desktop environment, file explorer etc. Traditional packaging (rpm/deb) packaging is absolutely the right way to go here. It is the tool to be used by OS developers to make sure that the system is compatible, just works, and can be updated without breaking stuff.

2) The other use case is users wanting to install "apps" from 3rd parties. The situation here is different because the developers of 3rd party apps are usually not well suited to create packages on the OS level (rpm/deb). In an ideal world, the 3rd party developers would make a release and then the OS developers would package this release and distribute it to the users of their OS immediately. But that is not feasible, as no OS developer can keep up with all the releases of apps. The reality is that 3rd party developers end up having the burden of package management, and it is obviously tedious for them if they have to provide many different packages in different formats for different (Linux) users. In addition, 3rd party developers are generally less trusted to provide security updates etc. This is where flatpak comes in: It provides a simple way for 3rd party developers to provide a package for all Linux users which is secure and (hopefully) just works. This is the best option specifically for those apps which are not already packaged by the OS developers.


Last edited by Mr. Pinsky on 30 July 2021 at 12:37 pm UTC

Quoting: ZlopezI think the flatpaks are really great (I'm using distro, that is made for use with flatpaks), but there is one issue with Flathub regarding games, the runtimes (shared libraries between flatpaks) are updated continuously so you still have the same issue like with current Linux OS, the libraries will be incompatible in a few years. ...

Libraries do not get incompatible by themselves. This always requires a conscious decision by the library's developers, and unless they are utterly incompetent, they will not do any ABI breaking changes without also changing the library soname and therefore allowing multiple versions of the library to be installed at the same time.

What happens with traditional packaging is that distributors at some point stop packaging outdated library versions.

I'd be curious about the policy at Flathub: Do they plan to remove outdated, unmaintained versions of libraries from future runtime versions, or are they committed to keep some ABI compatible version of each library present (like Valve does in the Steam Runtime)?

Quoting: PopeRigby

Quoting: PublicNuisanceI don't have a horse in the race but here is an article worth reading as devil's advocate.

https://flatkill.org/2020/

Reponse from one of the Flatpak developers: https://theevilskeleton.frama.io/2021/02/11/response-to-flatkill-org.html

Thanks for the link. I read through it and came away with mixed feelings. They basically said that they agree with much of what the original article had said but then tried to accuse them of inciting fear in the Linux community. If much of what they had said was indeed correct then I wouldn't care about what it incited, I would get to work on fixing those issues. On the flip side they do give some valuable advice on how to mitigate some of the issues as well as point out that no software is ever 100% secure which I agree with.

Quoting: KlausDEB/RPM Packages, if available, may be broken or at least incomplete for any given configuration. Often the only officially supported Linux is Ubuntu, on OpenSuse I often have to install things more manually, or fix things afterwards.

Additionally, adding non-repostitory software to the system has its risk. Installing OnlyOffice from a package left me with .so files that suddenly interfered with the build-and-run process.

By contrast, I'm never seeing similar issues on Windows. Software comes prepackaged as an installer, and the installer contains everything that's needed. (But sadly, Windows installers integrate Software too deeply into the system for my tastes.)

First thing first: Please do not take this as an actual suggestion. I just want to highlight that there's another way to package applications for Windows, Linux, etc.
Namely: portable packages. So, basically what most Windows installers do anyhow, but without any deep integration into the OS. Just bundling the program's executable and its dependencies in an archive file that users can extract to and run from wherever they like. Or go even further and just use static linking. I mean, on Windows most programs bundle their own copy of shared libraries anyhow, so what's the advantage over just statically linking those in? Actually the Unity Player does that, at least on Linux (for good or worse - having SDL2 statically linked is causing troubles for modders who want to talk to SDL2 from their .Net code...).