One thing about flathub is that they can be added by someone/anyone to flathub. Although there is a disclosure in the fine print, it can cause issues with applications when it’s not fully supported by the developers. Example:
Blender : It does not properly work with other applications as is expected (can’t communicate to Krita or others)
Bitwarden : An extremely long thread on their forums is ongoing to support/take over the flathub repo has gone on deaf ears. The community supports as best as it can.
KeepassXC : The flatpak cannot talk to a flatpak’ed browser like flatpak Firefox. This basically breaks usability and apparently is caused because of not being developed to use Portals
Syncthing : An update to the latest Release is broken on flatpak due to compilation and use of libraries. The community cannot update this without Dev help, so Syncthing is stuck on an old release.
These are just a few examples to things or scenarios that can occur in a project not fully supported. Fedora packaging a Flatpak would at least ensure some better compatibility if done properly, not to include the often late to update runtimes on many projects.
Some times I think user knowledge of how Portals work is better to avoid confusion. Sandboxing as a feature or side effect of flatpak is a good thing, but often falls to mean other things than what the project is for, and that is Universal packaging. Sandboxing can break certain software usage as a need for /home , /home/Downloads is important for usability, but that brings us again to how Portals actually work and the knowledge thereof.
None of the above issues would be fixed by having Fedora package those Flatpaks. They all require development and thus the cooperation of the application developers.
Flatpak’s whether from Fedora’s repo or Flathub’s are technically built in the same manner. Fedora uses it’s own runtime, which is derived from the freedesktop.org runtime, just as Gnomes is. The universal aspect is of course that the app being packaged is bundled with all dependencies, and the runtime it depends on is responsible for supplying the core system usability. But it also depends on the runtime chosen, and I would think the runtime has some determination over interoperability.
I actually disagree with this to a degree. Sandboxing an application from the OS means a lot more than just having it not be a part of the underlying OS itself, but also being isolated from the system entirely. For example: systemd-nspawn -dB effectively does this type of sandboxing as the applications cannot easily talk to the one inside of the nspawn container, nor can the nspawn container talk to the system easily. Another example would be one we used to do a long time ago to do what flatpak does now if you give it no access to /home/<User>/.
SELinux sandboxing via policycoreutils-sandbox with the command sandbox -X -w 1920x1080 -H temphome -T tmp -t sandbox_web_t firefox & This is true sandboxing of an application. I think there is a miscommunication of the terms “sandbox” and others when in fact we just want Universal Package management. Which we have the format, just not the support as a whole.
I think that as a community, being more vocal of the change and direction the project goes regarding Universal package Management, would help in persuade Developers to commit to a change or timeline for one.