I like the idea of being able to manage/install flatpaks through dnf/yum in the same way as we do with rpms... but I'm worried that it could be a problem if we source them from a 3rd party like Flathub. In the case of Flathub, their policies regarding what can be distributed and how it can get built are incompatible with the policies that we enforce from Fedora. Many of their packages have bundled binaries, and could be using code that is incompatible with our policies, so for this to be viable I think it would be reasonable to limit the packages to come from a trusted source (like the Fedora flatpak repository [0]). That being said, an alternative would be to build and distribute flatpak bundles [1] through RPMs, that way you don't lose control on how flatpak packages are built, and it would make it easier to differentiate them from the ones that are installed directly from other sources. Another idea would add the ability for dnf to manage the flatpak apps installed on the system directly through plugins / patches ... but IDK how practical / viable / maintainable that would end up to be... Diego [0] https://registry.fedoraproject.org/ [1] https://docs.flatpak.org/en/latest/single-file-bundles.html On Sat, Nov 9, 2024 at 12:49 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > Flatpaks are the new wave of installing desktop packages. Both GNOME and KDE graphical install/update programs work with flatpaks. > But what about dnf/yum? > > I would really like to install, and update, my flatpaks the same as I do rpms. > > FAR > These are the packages that you would see in epel. They would be in the format: > flatpak-<package>-<repo> > flatpak-firefox-fedora > On installation, they would ensure that the flatpak remote repo is added, and then install the package globally via flatpak. > On removal, it would remove the globally installed package via flatpak. > > FARU > A bit more complicated, but very do-able. > faru would create it's own local dnf repo, as well as add the faru dnf config pointing at that local dnf repo. > At regular intervals (daily?) it would look at the global flatpak packages installed. If there isn't a far for them, it will create one. It then looks at the remote package versions to see if there is an update. If there is an update, it will create a new far, and put it in it's repo. > > Then, whenever the machine updates it's rpms, it will update it's flatpaks as well. > > What do people think? > I'd like both positive and negative feedback. But I'd also like explanations/reasons for all feedback. > > Troy > p.s. No, I haven't done anything other than in my head. I would be surprised if I was the only one to think of this, so I'm expecting someone to point me to a similar project that I didn't see. > > -- > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
