Flathub to verify first-party apps and allow developers to collect monies

By - | Views: 19,194

Flathub and Flatpak packages are the future of Linux apps, according to more people, and GNOME are continuing to invest in it. They have some big plans to improve it too.

Writing in a new blog post on the GNOME Foundation website, they went over a number of things and not just Flathub related but that's what we're going to focus on for this article. The plans actually sounds pretty good!

Firstly, Flathub is going to gain a way to process and verify apps from first-party teams. As in, developers who directly publish their app and manage the Flatpak package process for Flathub. A way to actually properly distinguish official apps from community builds will be quite important for so many reasons (security, privacy and so on). Not only that but GNOME want to give developers a way to collect donations and subscriptions too, which is also important to help make it more sustainable. Sounds like it's possible a way will be added for developers to share some of the revenue with Flathub too, ensuring it too is sustainable.

To improve the experience further another part of the plan is to support multiple repositories, to enable a split between these first-party apps and community contributions, and have one where only free and open source apps live. That way, users get more of a choice on what they see and it just gives a little more control over all. Part of the hope is that they can get GNOME Software and KDE Discover to support all this, and note it all like verify apps and such. Think of it like see a nice big blue tick in whatever software store you use to see clearly it's official.

You can see the plans in a bit more detail on their original Discourse post.

Also be sure to check out a pretty good video overview on Flatpak from Nick at The Linux Experiment:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link
Article taken from GamingOnLinux.com.
Tags: Apps, Meta
27 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
49 comments
Page: «3/5»
  Go to:

nosklo 23 Jan
Look at it from the application developer point of view:

deb/rpm and even AUR requires a maintainer; It's extra work for the developer that takes them away from the actual code to do packaging.

Programs these days update quickly, multiple times per day. It is not feasible to have a volunteer package maintainer for each distro.

Also look at it from the end user point of view:

Installing/updating a program by doing something that is not just clicking a button is too hard for most people.

Naive users depend on latest version of niche programs to do stuff; they have to be easily installable and upgradable.

Linux wide adoption depends on this. It doesn't matter for us that already know how to use linux the way it is, but it will make a huge difference for wide adoption.

With Flatpaks, the app developer makes a single package for all distros and that is it; If the application is open source, the package maintainers can still package it differently if they want. But the developer can have a single target and reproduce the bugs in a replica of the same environment; Flatpaks are a dream for end user application developers.


Last edited by nosklo on 23 January 2022 at 12:09 pm UTC
AussieEevee 23 Jan
To be honest, if it ever gets to the point where I HAVE to use Flatpaks, I'd probably go back to Windows.

Choice is good, but there is just far too many things I hate about flatpaks. I just don't think it's a viable alternative to debs.
slaapliedje 24 Jan
View PC info
  • Supporter Plus
Quoting: pleasereadthemanualFor proprietary games, sure. And for distributions on a slow release schedule with frequently like Debian, Ubuntu LTS, and even Ubuntu proper, sure.

On a rolling-release distribution like Arch? No way. All of the packages are up-to-date, and if they're not, they are up-to-date in the AUR. Flatpak is way too much complexity for me. I tried it when I was new to GNU/Linux and it confused the hell out of me. I'm sure I could manage it now, but I don't want to. I don't mind AppImages because they tend to manage themselves and aren't particularly ambitious. However, even they tend to have less features than the non-sandboxed version (see the Cinelerra-GG handbook for the differences).

I'd rather games come with a .sh install script like GoG games do than be required to deal with Flaptak. I see no place for it on distributions like Arch Linux.
The downside of that of course is you don't get notified when there is a new .sh installer.

So I think the negatives of AppImages is that they will cause duplication of libraries. Flatpak actually depend on the flatpak library version it needs, so should take care of that problem, though it still won't use system libraries, so does cause duplication there. Flatpack installed packages having their own library downloading seems like it could be a different security layer than say one you got via 'apt install <package>' though.

But for sure, Flatpak / AppImage is useful for distributions that are a little bit slower to release updated software.

AUR also has some downsides, like people getting bored of maintaining the PKGBUILD, and it becoming orphaned.
View PC info
  • Supporter
While checking to see if Flatpak supports musl-based distributions like Alpine (it does), I found the antithesis to this article: Flatpak is Not the Future. Well-reasoned and includes points that I simply didn't know about.
Quoting: AussieEeveeTo be honest, if it ever gets to the point where I HAVE to use Flatpaks, I'd probably go back to Windows.

Choice is good, but there is just far too many things I hate about flatpaks. I just don't think it's a viable alternative to debs.
I can't go back to windows.. no way no how.

It'll be BSD for me next if I have to, I don't mind it I've had past experience with it so I'm fairly familiar with it.
sudoer 25 Jan
Flatpak is the future for stale distros still living in the '90s. For rolling distros (which IS the future) it's useless and stupid.

Switch to a rolling distro and you will never have dependency hell issues again, nor bloat your system with disputable package formats. Having a big amount of different flatpaks can also lead (internaly) to dependency hell.


Last edited by sudoer on 25 January 2022 at 1:50 pm UTC
But we have OBS (Open Build Service) which can build packages for all major distributions from the same source in parallel including AppImages and flatpaks o.o

But yes, I agree, building a package once and distribute for all is a lot easier nevertheless. I already use flatpaks on purpose even tho the package is also in my distro in the latest version available simply to separate optional applications from my system updates and to let the flats update automatically.
Also because of flatseal to sandbox some applications I'd rather not want to have full access to my system.

I think especially for proprietary and of course payed software flatpak should be the go to solution.
Quoting: sudoerFlatpak is the future for stale distros still living in the '90s. For rolling distros (which IS the future) it's useless and stupid.

Switch to a rolling distro and you will never have dependency hell issues again, nor bloat your system with disputable package formats. Having a big amount of different flatpaks can also lead (internaly) to dependency hell.
I don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

So if it was genuinely the case that some particular "rolling release" distro did not suffer dependency hell, it would have to be because of a superior package management system or people doing packaging for the distro just being really good at it. To call things what they are, since there's only one really significant rolling release distro (well, technically Debian but nobody thinks of it that way, particularly not people evangelizing about rolling release distros), it would have to mean either the Arch maintainers just happen to be wiz, or pacman was significantly superior to debs at avoiding dependency issues.

If it's the latter, maybe everyone should just be switching to pacman. But is it really even true that Arch is better at avoiding dependency problems? And are those even much of a deal any more?


Last edited by Purple Library Guy on 25 January 2022 at 4:07 pm UTC
sudoer 25 Jan
Quoting: Purple Library GuyI don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

No, the secret is in the libraries, check the 2 points here.

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

And furthermore, the AUR is such a good system which contains all the scripts for the user to build the software, always against the newest libraries! Plus it has ONE version, not 20 different PPAs with prebuild binaries, 10 different OBS places with incompatible/dummy-packages and whatever.

IMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

see: https://www.youtube.com/watch?v=rmXNLK3pWko&t=1644s


Last edited by sudoer on 25 January 2022 at 5:24 pm UTC
Quoting: sudoer
Quoting: Purple Library GuyI don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

No, the secret is in the libraries, check the 2 points here

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

IMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.
Waitaminute. So as far as I can tell, that link says Arch always uses just the latest versions of all libraries, and then deals with the problem of applications that might need different versions of a library by just dumping applications that can't keep up.
Well, sure, that's one way to avoid dependency issues, but it's not much use if I want to use that application. And it has nothing to do with either being a rolling release or pacman managing things better. It's just a very ruthless approach to running a distro.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.