Hmm…
Along those lines..
Full linux containers as artifacts don’t have dependencies… so its not as simple as that.
Would having fully qualified namespace means applications on one remote can depend on runtimes offered on another remote? That would be very interesting.
Could we or CentOS offer platforms in our remote(s) that application upstreams served out of github depend on?
What does a future look like when individual upstreams not only take control of their flatpak binary outputs, but also take more control of their distribution channel for official flatpak outputs?
I keep thinking about a possible future… where flatpak is recognized as the defacto platform that encompasses not just bare metal linux desktop installs.. but also WSL2 linux environments… and github wants to offer a flatpak remote service as distribution channel primarily to serve those WSL2 environments (but would work equally well on all linux desktop environments).
That future definitely needs different UI, with a way to clearly designate “official” upstream releases because github’s remote would be a pile of soft forks (just like “traditional” full linux containers). For a future that encompasses WSL2 it might be the commandline tooling is sufficient UI.. it might mean an entirely different GUI than what either the two dominant rival native Linux desktop environments want as opinionated GUI. But I see that future out there…
And that future really puts an emphasis on what “official” upstream builds are.
Flathub sort of anticipates a version of that future. They have the verified concept. The subset stuff is a bit wonky because its not actually a set of independent tags.. its just a field I think… which makes it combersome to extend in combinatorical intersting ways efficiently. Which is why I think its hard for them to add a designation like “built from source” which is something we want to see and be able to apply abstract filters on. Again hindsight is 20/20. But because we are selves aren’t attempting to do any of the subset stuff in our own infrastructure we aren’t in a position to collaborate with flathub to help get to a more flexible subset concept that all remotes can implement.
The future we need to get to invovles taking the subset concept further and making it possible to filter in more abstract ways.
What are “official” releases… what are “official floss” releases… flathub has covered. I’m not sure the GUIs expose that yet… but the cmdline tooling has a subset filter concept that does. Which may be sufficient for the future that includes WSL2 environments.
What are “certified secure official releases that meet objective security criteria from such and such 3rd party” not a question that can be answered at present. And I’m not sure the subset metdata as I understand it is flexible enough to answer that yet. But that’s exactly the sort of thing I interpret some members of FESCO saying is needed. But we’ve got no skin in the game right now, because our remote isn’t doing anything with regard to subsets.
I want to hold us to the standards we say we want. I want to be able to stand up a fedora remote in such a way that we grade whats in our remote… and we build a working example of subset metadata that flathub can choose to take from us instead of us telling them what they should do. I want us to lead by example. Which means we need to give our Flatpak remote a mission that requires us to use subsets to expose grading on a flatpak package by package basis and requires the UI tools we put in from of users to expose the subsets in a way that is filterable. One such mission is security. We say we care about it, but we don’t actually have objective tooling that would allow us to say with specificity which flatpaks meet which objective gradable security criteria. We can make it the mission to work on that and to start tagging via an extended more flexible subset mechanism and start grading our own stuff. Then we can start using the exact same tooling and grade official releases in other remotes and put a stamp of approval on those as well in partnership in those remotes. We can just start with flatpaks we provide where we grade by which flatpak sandbox static permission overrides they use out of the box. That a security grading we can try to label in metadata… if we had the correct metadata. That’s something we could lead on.. and then partner with flathub and flatpak tooling. If the 3 and counting searchable flatpak GUIs don’t want to expose that…that’s their choice..GUIs get to be opinioned and get to differentiate from each other.