Include libspelling, flatpak-rpm-macros and flatpak-runtime-config packages #1355
Conversation
These are used to produce RHEL Flatpaks
Used by GNOME Text Editor and Papers and currently being added into RHEL 10
| - flatpak-rpm-macros | ||
| - flatpak-runtime-config |
There was a problem hiding this comment.
buildroot only? If so, maybe move these to the end of the list and precede with a comment?
There was a problem hiding this comment.
No, they're shipped in CRB.
|
How is this going to work for ELN though? The rawhide branch of flatpak-runtime-config was retired as "modular only" (this was prior to my involvement with flatpaks, and while they were still actually modular). Does this mean we need to unretire the rawhide branch and start building it there too? (Without doing so, the package is blocked, so it can't even be built manually into ELN.) Also, are you planning on shipping flatpak-container-tools in CRB? |
That's a good question that I don't know the answer for - will have to check with Owen, but the package is still included in RHEL 10's Runtime and SDK.
AFAIK No. We were not shipping even the flatpak-module-tools. |
As you know, flatpak-runtime-config and flatpak-rpm-macros ares currently built manually into the f-flatpak-runtime tag - there's no particular reason that they couldn't be built into the main tags instead - they have some potential to make things weird if a user if a installs them accidentally, but I'm sure there are other packages like that in Fedora. Would that make things simpler?
I think the way we'd want a RHEL customer to consume flatpak-container-tools is via https://quay.io/repository/flatpak-container/flatpak-build - if there's customer demand we'd look at making that an official Red Hat container rather than shipping flatpak-container-tools in CRB - the flatpak-container-tools CLI is basically only useful in the context of Koji. |
See individual commits