On Sat, 9 Nov 2024, Troy Dawson 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.
I like the idea of having one install/update system that manages
both rpms and flatpaks.
I think rpms being first class citizens is the right way around.
Do flatpaks ever exist as source, ie the equivalent of an srpm ?
Dependencies. Do flatpaks share or duplicate common libraries ?
One of the arguments for these sort of package containers
was that users could install them without root.
Will far defeat one of the reasons why users want flatpaks ?
-----
I imagine that some flatpaks are quite big.
Does flatpak have incremental updates ?
Should these be included in your system, a bit like drpms ?
I don't know enough about flatpaks to know whether a drpm for each
flatpak-version pair is the right or wrong way to do this,
but if the rpm is just a wrapper pointing to a flatpak, I doubt that
making a drpm from two different versions of an rpm is sensible.
-----
Organisations may wish to have a site-wide dnf repo for fars.
I don't see any difficulty here.
-----
Before anyone suggests a similar project for snaps:
one, does anyone other than Cannonical use them ?
Two, unless you rebuild each snap, there seems to be no way for
sysadmins to enable (read? write?) access to specified
areas beyond the compiled in defaults, so institutional
shared directories are not accessible from snaps.
I vote against a similar project for snaps.
--
Andrew C. Aitchison Kendal, UK
andrew@xxxxxxxxxxxxxxx
--
_______________________________________________
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
