Yes, users that will not enable third party repositories (and thus Flathub) will be limited to the set of Flatpaks that are deemed to be of high quality enough to be included.
This change reverses the logic. Uninformed users currently end up with a mix of working and non working apps.
Removing the filter for the Fedora Flatpaks becomes an explicit action and you accept the downsides that comes with the Fedora Flatpaks.
Totally agree, for some of the audience of Atomic desktops (me and family members) security isnāt the highest priority. Sure it is nice, but it falls behind user experience. Whatās better with Linux is that we believed that Atomic desktops were made for me as part of the audience, and for those who are more privacy oriented, then there are plenty of other distros that allow for that customization for security and privacy.
Let me point out that Google Play currently eventually stops letting me install applications that are built against very old verions of its API.. because of security.
In fact both Google Play and Apple iOS store both require applications developers to supported target minimum API partly because ofā¦ security.
this is not an RPM view. Iāve worked in those propietary walked garden as an applcation developer and they have made similar assessments that at some point the application store steward must gate on security to the benefit of the user in such a way that it impacts the application developer who is never incentivied to care.
Let me clarify a few things here as I feel that the subtleties are missed.
Iām not against removing/delisting apps because they are unmaintained or using EOLād runtimes. If we want those things to happen in Flathub then it needs to happen there. Flathub is in the same boat as Google here. They will have to remove the older runtimes at some point as they can not keep them forever.
What Iām against is setting up a filter for Fedora users only because we know better which apps are safe or not. We should work with Flathub instead to actually make it happen.
safe or not? I doubt any of us can know that. The best we can do is attempt to assess risk.
Something can be very risky and still safe and something can be low risk and unsafe.
PassVault as an application for example is clearly no longer maintained. Is it safe? I have no idea. Is it risky? yes. Do I think the software UI does a reasonable enough job of informing the user of that risk. Absolutely not. Because the warning is below the fold in Gnome Software.. i have to scroll down to see it and there is no nag dialogue. KDE Discover lets me hit install without even seeing any of the details at all. This is the sort of thing Google Play store would prevent me from installing based entirely on the grounds that the SDK version it was built againstā¦ 4 years agoā¦is no longer maintained and that presents too high a risk to the user.
The EOLād runtimes are clearly no longer maintained and by association so are the applications that depend on them. Are those runtime inherently risky? Yes. Do they get riskier with age? Yes. is qt 6.6 runtime more or less risky than the freedesktop 20.08 runtime?
Not sure how to answer that unless we have the flatpak equivalent of SBOM scanners in development for linux containers right now. Without that tooling how do we access risk on a case by case basis? The flatHub policy is so all over the place that without something like an SBOM scanner that users can individual use to make risk assessments at time of install and periodically after thatā¦ its very difficult for anyone to make informed choices with regard to risk.
I donāt know which way this proposal will go, but it does seem like a good opportunity for the community to better understand Flathub so that Fedora feels more comfortable leaning on contributing to the project. Flathub is already in the mix of repos for many users be they Atomic Desktop users or not, so increasing trust in Flathub through clarification or work would be helpful for this.
The reason I say this is because I agree that Fedora Flatpaks donāt seem to be a long-term solution for any problems a user might face. The only use case is the narrow one that weāre trying to limit to with this proposal. Unless something will change with Fedora Flatpaks, it doesnāt seem good to be in this limbo.
Iām not convinced that flathub is a long term solution either. Itās marketted as such yes.
I think ultimately both github and gitlab will spin up flatpak remote services for upstream projects and those services will be preferred by upstream project developers as the least friction way to produce linux distro agnostic binaries. Once that happens flathub is just one of many peer agnostic remotesā¦and it wont even be clear it will be the preferred remote.
Whatever we do we should prepare for that future.
I still have unresolved concerns about being able to pull corresponding source for the floss labelled flatpaks obtainable from Flathub in a consistent manner.
Even with the additional information on how to use the Sources extension now documented, which was very helpful and important to be written up, I still cannot find the sources for critical pieces of the floss subset on offer from flathub. This is a problem.
I point it out because there doesnāt be a coherent policy at flathub on how to deal with this and I think people are assuming its being dealt with in a reasonable manner. If it were I shouldnāt be running into pitfalls like this when trying to verify. This is a problem.
Current example that Iām trying to find the sources for.
org.freedesktop.Platform.openh264
I install it and look at the files/ that are mounted and I donāt see a manifest at all. The documented cat command to extract the manifest doesnāt work. Thats problem 1.
I then try to pull the Sources extension following the new documentation and I canāt. Thatās problem 2.
This is a binary that is part of the floss subset as labeled by flathub. I even setup a floss subsetted remote on my system in an effort to ensure I was only going to be examining floss flatpaks for corresponding source availability or at least breadcrumbs.
Iām stuck. Iāve no idea what sources this floss binary is pulling. There are no breadcrumbs back to the sources afaict, nor is there tool assisted help to pull the sources, nor is there any documentation included that I can find that points to sources. None of the currently documented processed by which to pull the flatpak manifest appear to work for me.
I do this for the equivalent rpm in the cisco partner repo we enable in Fedora and I can pull and install the srpm without an issue and on inspection of the rpmbuild directory I see the corresponding sources.
I would argue that Flathub is actively making moves to provide longer term sustainability for open source developers. One example is making sure developers have the option of getting paid for their work similar to how competing appstores on Windows and Mac function. This is a really important goal for the greater ecosystem that Fedora flatpaks does not address.
There is also the network effect taking place where if a developer knows they have the opportunity to be financially compensated (and there is an already built-in audience on a platform), I would argue they wouldnāt want to use an alternative to host their app even if itās āeasierā (similar to how users would prefer hosting RPMs in Fedora repos over Copr). Developers want to go where the users are.
I think Fedora should be trying to work with its partners instead of trying to reinvent the wheel. I know there are problems with certain things on Flathub, but we can help provide feedback on those issues and help address those issues to improve the greater Linux app ecosystem.
I do not want to discount concerns you have. I do think we can address them and provide a better experience on atomic desktops at the same time. I donāt think those goals are mutually exclusive.
Thereās nothing stopping from Fedora Flatpaks from including a donation link to the upstream project.
And if youāre referring to actual paid apps, I have some concerns to how Flathub would approach this. Thereās two underlying issues in my eyes.
Could this be the reason why there is no manifest file for openh264?
I can only speculate as to how flathub decided to deal with the thorny issues that Fedora has to deal with as they move forward with their LLC model. I am not privy to the discussion.
But considering that the Fedora solution to solve the software patent issues for this particular peice of software still makes it possible for me to pull corresponding source via srpmā¦ tells me the choice to drop it is orthogonal.
Regardless in the flatpak world where I can downgrade to past versionsā¦ there is a need to provide corresponding source for all the versions that you can download. Doesnāt matter what the future holds in terms of removing it later.. if a version of it is downloadable right now and its part of the floss subset I have an expectation that I can get the full corresponding source. Flathub isnāt meeting that expectation right now. Thatās a problem right now.
Regardless of the stated concerns in the proposals about Fedora Flatpaks. Even if we all agree that those are correctly statedā¦
The fact remains that Fedora flatpaks have a coherent build from source strategy.
Itās not all roses, it does need investment to ensure users can get corresponding source.. but its coherent.
Amazingly when I try this command:
flatpak run --command=rpm org.fedoraproject.Platform -qa
I get a list of rpms and from that I can go looking for the corresponding srpms and grab the sources.
But that command doesnt work on the org.fedoraproject.Platform.VAAPI.Intel flatpak and if I examine the files for the installed and active org.fedoraproject.Platform.VAAPI.Intel flatpak I canāt find any breadcrumbs for the corresponding source there as well. That is a problem for sure, because of the nature of rpm updates its unclear what the corresponding source actually is for this thing.
Is this a great corresponding source story for Fedora flatpaks. Nope. It also needs to be enhanced, but because those flatpaks are composed from Fedora rpms I see a way forward to enhance the Fedora flatpak tooling to include the srpm list that lets users pull the corresponding sourceā¦ because everying Fedora offers goes through the same build automation by design.
I dont see a clear path forward in the same way for flathub becaue of the pourous nature of flathub policy with a lot of exceptions and very few requirements. The trusted 3rd parties get a lot of leeway.. too much leeway. flathub seems to have automation around manifests and sources extension for some things but not others. Is that fixable? Feels like whack-a-mole space and lots of differences of opinions that have to be navigated and not something easily addressed with tooling enhancements.
And to be very clear, the flatpak Sources extension, if used consistently, probably has a great trajectory as a technical solution to solve the corresponding source problem generally for flatpaks.. across the flatpak ecosystem regardless of OCI/ostree images or whomever the flatpak vendors offering up flat registries end up being. If Fedora is going to continue to provide flatpaks, we should probably figure out how to make use of the Sources extension to bundle corresponding source together for all the flatpaks we produce.
following that discussion.
trying to pull the Sources extention for org.freedesktop.Platform.ffmpeg-full using the newly documented approach also fails for me with an error about a dash in the name.
So im stuck again.
This works:
flatpak install flathub org.kde.minuet.Sources
This doesnt:
flatpak install flathub org.freedesktop.Platform.ffmpeg-full.Sources
error reads:
error: Invalid id org.freedesktop.Platform.ffmpeg-full.Sources: Only last name segment can contain -
is this a tooling error or something else. No idea but it makes it impossible to get what should be the corresponding source. thats a problem.
And if I go looking into
/var/lib/flatpak/runtime/org.freedesktop.Platform.ffmpeg-full/x86_64/22.08/active/files/
There is no app/ directory and there is no manifest file that I can fine. Thats a problem.
So here again I have a flatpak that seems devoid of any information concerning corresponding source.or even breadcrumbs to the corresponding source. Itās obstensibly floss.. but it might as well be just a runtime of proprietary garbage.. because as a user I canāt take the sources and rebuild it afaict.
That would appear to be an error due to very strictly enforcing I believe a DBus standard (might be XDG, been a bit since I last looked at which standard itās a part of) that hyphens / dashes are never to be used aside from the very last segment of the reverse address / TLD
So org.freedesktop.Platform.ffmpeg-full is valid because the segment with the hyphen (ffmpeg-full) is in the final position. org.freedesktop.Platform.ffmpeg-full.Sources, on the other hand, would be invalid by that standard because the last segment is instead Sources (and consequently, there is a hyphen in a section that is not the final one).
So that sounds like an issue that should be addressed by making Sources a special keyword / changing where you specify you want the sources (moving it to the other end, maybe?).
That doesnt change the fact that the content of the installed flatpak doesnāt include a manifest either that i should be able to locate under the app/ directory inside the flatpak according to Flathub documentation.
The point is, the corresponding source story for flatpaks is a mess right now. I would love it if Flathub was leading the way here.. but on inspection I canāt claim that.
Right now, I can see a way forward with Fedora flatpaks to address this to a sufficient extent with tooling investments because Fedora flatpaks have a coherent source policy. It should be relatively easy to inject a list of src rpms into each flatpak, the build tooling just has to be extended to produce that list. A little more work in the tooling translates into a win for the full collection maintained by Fedora.
I donāt see the path forward for flathub because its not a coherent collection with consistently applied policy.
I was speaking exclusively about the error you reported regarding flatpak install flathub org.freedesktop.Platform.ffmpeg-full.Sources and nothing else because I recognized what was happening there.
This seems like it creates a pretty significant usability problem for people who arenāt educated on filters flatpaks and how everything works.
A user is going to open the software store to install software and see nothing. That seems like a rough first impression.
sure.. possibly a tooling errorā¦but makes you wonder how the Sources could be uploaded if the naming doesnt allow it.
But lets try another one real quick.
This works:
flatpak install flathub org.freedesktop.Platform.GL.default/x86_64/24.08
This doesnt:
flatpak install flathub org.freedesktop.Platform.GL.default.Sources/x86_64/24.08
error: Nothing matches org.freedesktop.Platform.GL.default.Sources in remote flathub
and if i look down in
/var/lib/flatpak/runtime/org.freedesktop.Platform.GL.default/x86_64/24.08/active/files/
I donāt see anything that looks like a flatpak manifest.
Its hit and miss in terms of what I find in the floss subset that has either sources or a manifest exposed. And as Iāve already pointed out the manifest is not always sufficient because of the use of sources of type patch and file that are not pulled from a url at build time but exist in whatever repo holds the manifest.
an example of what i would expect to see is
org.freedesktop.Platform.VulkanLayer.gamescope
the Sources exist for this and it includes the manifest.
Its just a mismash in flathub as to what actually provides Sources and/or manifests and what doesnāt, it feels like individual developers just decide what approach they are going to take and thereās no tooling to enforce a corresponding source policy for the floss subset.
This is a problem.
The donation thing is super interesting considering the history of donations efforts exposed in the UI in the past. There have been several, but the one that I think about the most when thinking about flathub LLCās plans is twhat happend around the 2011 timeframe involving a different linux distribution project. It would be uncouth for me to name names, but I canāt help but think about how that was recieved.
Iām cautiously wary that it will be successful without some sort of similar drama this time. Hopefully flathub LLC can provide enough transparency to understand how much of those donations end up going to the upstream projects themselves and how much is being used for flathub overhead. Transparency will be key in avoiding some of the same problems from the past. And being a middle man between users and upstreams, with regard to donantions and intentions, can get messy and burn up good will. I wish them the best of luck in threading the needle on this. I really do. Money is a hard thing to navigate.
I also look forward to seeing how the donation and/or pay concept for flathub works outā¦especially in the light of the EU CRA legislation and whether they are then considered a steward or a manufacturer. Itāll be super interesting. I wish I could sit in on their discussions about how the CRA impacts their plans in this area. If a portion of those donations ends up funding flathub operations the CRA makes this even messier i think. Good Luck. Iāll be watching.
If they work it out with sufficient transparency then whose to say that distributed downstream forks wonāt be able to offer a similar donation scheme. It doesnāt have to be a competition that cuts off resources to upstreams. The devilās in the details as they say.