After today’s Community Demo I got interested into the topic of controlling and proxying Flatpak content again.
It was very shortly mentioned that pulp 3, or better said the pulp container plugin is capable now to download, host and index OCI compliant Flaptak repos now.
It kind of makes sense to do the same thing with flatpak repos as already done with yum (…) repos, “mirror”, stage, filter, and distribute them internally as they are mostly very user facing.
As far as I understood it, it would be possible now to integrate only OCI copliant single flatpak repos into pulp, but not the ostree/git style repos, and even less structures of many such repos like Flathub is.
It really got me thinking of a time, where you could on demand proxy Flathub through Katello, which could manage the Flatpak remote config on the clients via rhsm.
Up to now I don’t really know if I’m able to help in that matter without much development knowledge, or even have that time, but hey I at least I had that thought and wanted to write it down.
So… any thoughts on this? Did I misunderstand/miss something, is there already work somewhere for Flatpak remote proxying?
Pulp support is only the first step, but a promising one. I am personally not a big fan of flatpak, so I would prefer support for other content before this, but if there is some interest I am definitely pro adding it.
Okay good.
Lets say I’m also not the biggest fan, but it seems like it’s the future for UI applications…
And with control of Flatpaks from Flathub you could also do whitelisting. (would need similar enforcing like it’s possible with subscription-manager with dnf, where you can force to only allow repos from rhsm)
@iballou
You got me back on this topic again with your talk in the last Community Demo
The only thing that gives me a really hard time is, as far as I understand it, you won’t be pointing to a whole remote, right?
For the OCI way (RHEL, other EL, Fedora OCI remotes) you basically configure each image in a project, and then the future magic will give metadata on the project level to make it an flatpak remote?
For Flathub, I can’t even find a single OSTree endpoint for the individual packages, this makes it so hard to try around. Maybe I get it somehow working to sync a package with the OSTree pulp module, or at least get the git remote endpoint. Directory browsing is unfortunately not possible on Flathub
I’m hoping a full RFC for the feature is written up soon. The way we plan on handling it is by letting users configure OCI flatpak remotes for registries likes flatpaks.redhat.io and Fedora (in fact they should be there by default). There will be new UI workflows for that. Then, once the remote is configured, we’ll crawl the Flatpak index to discover the existing repositories. Finally, like on the repo discovery page, we’ll let you turn those discovered “repos” into actual repositories to sync.
We’d like to support OSTree flatpaks in the future too, but that’ll take a little more work since the Pulp OSTree plugin might need some additional work. We’ll gauge community interest after the OCI part is released. It might work out that you can turn OSTree flatpaks into OCI ones and then push it to Katello, but we’ll need to check that out more.
It’ll be helpful to see who’s interested in this feature, so for any other readers, please post here (or on the future RFC post) if you’d like to mirror flatpaks in Katello.
Ah it’s that “easy” okay, lets see how it turns out
Yeah for me it’s making the use case client support (with staged repos) complete and round in these flatpak rising days.
Will most likely spend some time in the next months to figure out how flatpak hosting, flat-manager and such works. Maybe it makes a little more sense then how the whole OSTree based thing is structured.
On Katello we use pulp to manage both flatpak and container images, since they are both OCI objects, flathub does not use OCI right now, I’m not sure if it’s on flathub roadmap to move away from the legacy artifact structure to move to OCI.
I’m sorry to say it like that, I’m really surprised about calling OSTree the “legacy artifact structure”.
I can’t find any hint in the Flathub matrix channel, Github issues/discussions, … that there is any thought about moving to OCI images for Flathub, it’s builder, linter, and so on.
It more so looks like Fedora (and world) is the only region, where the OCI artifact feature in flatpak is used.
Getting Flathub Flatpaks working in Katello first means getting them working in Pulp. Pulp Container has Flatpak implementation, which includes generation of the Flatpak index. We’d need to see the same effort in Pulp OSTree I imagine.
If Flatpaks can be synced via Pulp without much pain, then the Flatpak feature that we’ve built in Katello hopefully should not require too many changes to work with Flathub as well.
With this in mind, I think the Pulp side of it probably needs the most amount of work.
If anyone in the community is interested in working on this feature, or even just running some research on Pulp’s OSTree plugin and its compatibiltiy with Flathub flatpaks, I’m sure we core contributors would generally be happy to give support. If someone found out, for example, that the effort is lower than we imagine, it could potentially help with prioritization.
OCI Flatpaks were relatively easy to implement into Katello because we leverage all of our existing container content support. We were able to add some extra niceties (like repo scanning, dependency checking, etc) because of that speed to get the basic proof of concept going.
Oh yeah the big discussion, thanks for the reminder, still had to subscribe to that in the new Forge ^^
Yes I totally agree it’s still a long way until there might be the option to sync OSTree based flatpaks, and I would also never deny that it will be quite a bit of work to get that running.
A quite interesting part might be if pulp_ostree can be extended, or if it’s that different that it will need its own plugin.
Unfortunately it still reaches past my experience to do that task myself, which brought me more than once to (putting on company hat) put that on the request list for Atix
Some long time ago also started into looking into how the whole Flathub thing works at all, though didn’t get too far yet (doesn’t mean I won’t keep trying)
and the appreciation part!
Lets all be glad that OCI based Flatpaks could be integrated so easily, it’s one step forward (or maybe even multiple!), which is always a great thing to see
And more so, thanks for making that part already work so well on the usability side too, it’s not like this was a small thing to get the whole client integration part working!
Personally would like to see Flathub support in Katello. Since I’m able to add Fedora flatpak repo already.
