Closed zelikos closed 10 months ago
Since this is meant as a startingpoint module, and wouldn't be under bling, I assume the correct approach would be a separate PR to add the needed files into startingpoint rather than adding them into this repository? Or should they be put into a subfolder in the module folder? The specific file names can be changed to something else if needed.
For now, I've gone ahead and added the files into a subdirectory in the module, for easier testing of the module. If the proper approach long-term is something else, do let me know.
Hey, thanks for working on this in such a quick time span! I'm wondering if a name like default-flatpaks
or flatpak-manager
would be better for this one, since flatpaks
are so generic and might be managed by other modules (like yafti
).
Also, like yafti, the module in its current form would require certain files to be present...
Since this is meant as a startingpoint module, and wouldn't be under bling, I assume the correct approach would be a separate PR to add the needed files into startingpoint rather than adding them into this repository?
I've been meaning to move the default yafti config to bling, too. I think that is the approach you should take here. Then, in the module docs (README), just document where a user should put files to override. The primary way to configure here would be the yml, which writes into the files in /etc/ which are used by the main flatpak manager script like bluefin/bazzite do.
Edit: and the bin files should be put into place by this module, obviously (IMO), as they are literally the purpose of the module.
I've moved the files in with the rest of the bling files, and updated the module script to move them into the image from the new locations. Also renamed the module to default-flatpaks
for now (though it may be worth discussing which is better of the two options you gave? default-flatpaks
vs flatpak-manager
).
On that note, from the OP:
However, in hindsight, it might make sense to limit the scope to system-wide Flatpak installs here, as the per-user Flatpaks would be installed for every user with this, anyway.
You mentioned yafti
as another module that works with flatpaks. Since yafti
prompts the user, it's also a much better fit for per-user flatpaks. I'm thinking I should simplify this module to focus on system-wide default flatpaks. Or, I leave it able to do both system and user, but just document that user installs would be duplicated for every user on a system. I'm leaning toward the latter myself now, but what do you think?
I'll of course touch up the README once we've decided on the scope here
Would be great to add removal of fedora-testing repo too
I've marked this as ready for review. The needed files are in with the other bling files, and moved on to the image by the module script. All configuration is handled in the yml.
One thing I want to address in the future is to enable flatpak setup to run again automatically when the module configuration changes (like yafti), but I'm not really sure how to do so.
In a774b67 I tried to explain a bit more about the structure of /etc/flatpak/
, which I deem necessary. Feel free to correct things if I'm wrong and expand.
This PR really looks like it could replace yafti for me entirely, so cheers for that! :heart:
There are some updates for this in bluefin before merging though:
https://github.com/ublue-os/bluefin/pull/583 https://github.com/ublue-os/bluefin/pull/586 https://github.com/ublue-os/bluefin/pull/587 https://github.com/ublue-os/bluefin/pull/588 https://github.com/ublue-os/bluefin/pull/591
There are some updates for this in bluefin before merging though: ublue-os/bluefin#583 ublue-os/bluefin#586 ublue-os/bluefin#587 ublue-os/bluefin#588 ublue-os/bluefin#591
Thanks for this list. I'm wondering if bazzite-flatpak-manager has had changes too. This is one of the reasons I dislike the resistance to standardizing the source of ublue system components like this, projects adapt the same source for the same usecase in slightly different incompatible ways, bugs get fixed in one place and not the other, etc.
bazzite-flatpak-manager
: https://github.com/ublue-os/bazzite/blob/main/system_files/desktop/shared/usr/bin/bazzite-flatpak-manager
ublue-system-flatpak-manager
: https://github.com/ublue-os/bluefin/blob/main/usr/bin/ublue-system-flatpak-manager
Also a note that you need to quit Gnome Software before removing third-party repo prompt: gnome-software --quit
Before this:
# Opt out of and remove Fedora's flatpak repo
if grep -qz 'fedora' <<< $(flatpak remotes); then
/usr/lib/fedora-third-party/fedora-third-party-opt-out
/usr/bin/fedora-third-party disable
flatpak remote-delete fedora --force
fi
In a774b67 I tried to explain a bit more about the structure of
/etc/flatpak/
, which I deem necessary. Feel free to correct things if I'm wrong and expand.
That explains the structure perfectly. Thanks!
There are some updates for this in bluefin before merging though:
ublue-os/bluefin#583 ublue-os/bluefin#586 ublue-os/bluefin#587 ublue-os/bluefin#588 ublue-os/bluefin#591
Will get to work on doing these next
Updates from bluefin have been added:
Fixes and updates to repo configuration:
Added the notify-send
from bluefin as well, although in my own (brief) testing in a VM, the notifications were never sent. Poking around in bluefin's PRs, though, it seems it works for others? Either way, even if it doesn't work every time, there's no harm in notify-send
being there to report successful setup.
See #56
default-flatpaks
module for startingpointThe
default-flatpaks
module removes the Fedora Flatpaks remote that comes pre-installed by Fedora, and can be used to install flatpaks from a configurable remote on first boot. The Flatpak remote is configured the first time the module is used, and subsequent usages of the module will install flatpaks to the same remote. If no Flatpak remote is specified, the module will default to using Flathub.Flatpaks can either be installed system-wide or per-user, though per-user flatpaks will be installed for every user on a system. Previously-installed flatpaks can also be removed.
The module uses the following scripts to handle flatpak setup:
/usr/bin/system-flatpak-setup
/usr/bin/user-flatpak-setup
The scripts are run on first boot and login by these services:
/usr/lib/systemd/system/system-flatpak-setup.service
/usr/lib/systemd/user/user-flatpak-setup-service
system-flatpak-setup
checks the flatpak repo information and install/remove lists created by the module. It also checks for the existence of/etc/ublue-os/system-flatpak-configured
before running.user-flatpak-setup
functions the same for user flatpaks, but checks for$HOME/.config/ublue-os/user-flatpak-configured
instead.Flatpak setup can be run again by removing
/etc/ublue-os/system-flatpak-configured
for system-wide flatpaks, or$HOME/.config/ublue-os/user-flatpak-configured
for user flatpaks.This module stores the Flatpak remote configuration and Flatpak install/remove lists in
/etc/flatpak/
. There are two subdirectories,user
andsystem
corresponding with the install level of the Flatpaks and repositories. Each directory has text files containing the IDs of flatpaks toinstall
andremove
, plus arepo-info.yml
containing the details of the Flatpak repository.Example configuration