This is a tracking bug for Change: Flatpaks without Modules For more details, see: https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules Change how we build Flatpaks in Fedora to remove the dependency on modularity. Instead of using modules to rebuild Fedora packages with prefix=/app, there will be a separate build target that is used for that. If you encounter a bug related to this Change, please do not comment here. Instead create a new bug and set it to block this bug.
Owen, can you provide a status update here? How close is this to being 'testable' or 'code complete'? Thanks!
* Local builds of Flatpaks without modules have been testable for a couple weeks, and we've updated the runtime and a handful of Flatpaks to work in the new scheme. * The koji-flatpak plugin that we're going to use to build Flatpaks on infrastructure completed testing on staging last week (https://pagure.io/fedora-infrastructure/issue/11465#comment-869217) and was pushed to production. * We haven't started building Flatpaks in production yet (was waiting on https://pagure.io/releng/issue/11626) , but *as far as we know it should be all set now. * I would consider the code complete except for one bug: we have a problem with Flatpaks where the "main package" (e.g. kwrite) isn't named the same as the source rpm it is built from (e.g kate). I have local code to fix that, but may need an infrastructure freeze break to land, or to wait after the beta freeze. * There is also no fedpkg support, but that's not a blocker, in my opinion for this cycle. Can be documented: fedpkg flatpak-build => koji flatpak-build f39-flatpak-candidate 'git+https://src.fedoraproject.org/flatpaks/ghex#stable' fedpkg flatpak-build-rpms => flatpak-module build-rpms
Thanks. Let's call that MODIFIED, overall.
Is the current state documented in a way so that "ordinary" packagers can contribute by making their specs fit for flatpaking (and test it)? As soon as I see "module" in there (like in comment #2) I automatically think it's "pre-proposal info".
(In reply to Michael J Gruber from comment #4) > Is the current state documented in a way so that "ordinary" packagers can > contribute by making their specs fit for flatpaking (and test it)? As soon > as I see "module" in there (like in comment #2) I automatically think it's > "pre-proposal info". Docs about using it in the current state are restricted to: https://hackmd.io/@owtaylor/testing-flatpaks-without-modules Updating: https://docs.fedoraproject.org/en-US/flatpak/ Is something I'd like to happen for f39 GA - before that point, our goal is really to get the ~300 current F38 Flatpaks moved over to the new system rather than adding more.
(In reply to Owen Taylor from comment #5) > (In reply to Michael J Gruber from comment #4) > > Is the current state documented in a way so that "ordinary" packagers can > > contribute by making their specs fit for flatpaking (and test it)? As soon > > as I see "module" in there (like in comment #2) I automatically think it's > > "pre-proposal info". > > Docs about using it in the current state are restricted to: > > https://hackmd.io/@owtaylor/testing-flatpaks-without-modules > > Updating: > > https://docs.fedoraproject.org/en-US/flatpak/ > > Is something I'd like to happen for f39 GA - before that point, our goal is > really to get the ~300 current F38 Flatpaks moved over to the new system > rather than adding more. Thanks for confirming. So, "flatpak-module" is the right tool (despite module in its name), and I just have to hold it the right way[*] ;) [*] by editing the yaml as decribed in your doc
Yes, flatpak-module-tools and the flatpak-module binary are still the right thing, even though modules are almost entirely gone from them. I basically had trouble coming up with a good name for "Flatpak tools to work in the Fedora and Fedora derivative echosystem", and punted on renaming it. Thought about: flatpak-tools (flatpak-tool binary) hexwrench (hexwrench binary) [flatpak is a reference to the Ikea Flat Pack furniture] flatpak-rpm-tools (flatpak-rpm binary) Wasn't entirely happy with any of them. The plan is to have a complete wrapper for flatpak-module in fedpkg, (fedpkg flatpak-build-rpms, etc) so the name won't matter so much in the end.
(In reply to Owen Taylor from comment #7) > Yes, flatpak-module-tools and the flatpak-module binary are still the right > thing, even though modules are almost entirely gone from them. > > I basically had trouble coming up with a good name for "Flatpak tools to > work in the Fedora and Fedora derivative echosystem", and punted on renaming > it. Thought about: > > flatpak-tools (flatpak-tool binary) > hexwrench (hexwrench binary) [flatpak is a reference to the Ikea Flat Pack > furniture] > flatpak-rpm-tools (flatpak-rpm binary) > > Wasn't entirely happy with any of them. The plan is to have a complete > wrapper for flatpak-module in fedpkg, (fedpkg flatpak-build-rpms, etc) so > the name won't matter so much in the end. fedpak? :-) Nameshedding ...
Can we get another update on current status here, as we're nearing Final freeze? Thanks.
For F39 we currently have 52 Flatpaks built, including the main runtime and KDE runtimes, and most of the core KDE apps. We haven't started rebuilding GNOME apps yet, except for a few test example, but we're ready to do that now. (This is always done late in the cycle because its hard to build a new F38 app when the F39 changes are in git - we possibly should consider improvements, though that risks losing the simplifications we get by making Flatpaks "single stream") I would consider the change well tested at this point - any additional issues that come up at this point are likely to affect only a few apps.
F39 was released on November 7th, so I am closing this tracker. If this Change was not completed, please notify me ASAP.