feat: default-flatpaks module

[zelikos]

See #56

default-flatpaks module for startingpoint

The 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 and system corresponding with the install level of the Flatpaks and repositories. Each directory has text files containing the IDs of flatpaks to install and remove, plus a repo-info.yml containing the details of the Flatpak repository.

Example configuration

- type: default-flatpaks
  system:
    # If no repo information is specified, Flathub will be used by default
    repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
    repo-name: flathub
    repo-title: "Flathub (system-wide)" # Optional; this sets the remote's user-facing name in graphical frontends like GNOME Software
    install:
    - org.gnome.Loupe
    remove:
    - org.gnome.eog
  # A flatpak repo can also be added without having to install flatpaks,
  # as long as one of the repo- fields is present
  user:
    repo-name: flathub

[zelikos]

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.

[xynydev]

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.

[zelikos]

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

[fiftydinar]

Would be great to add removal of fedora-testing repo too

[zelikos]

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.

[xynydev]

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.

[xynydev]

This PR really looks like it could replace yafti for me entirely, so cheers for that! ❤️

[fiftydinar]

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

[xynydev]

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

[fiftydinar]

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

[zelikos]

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

[zelikos]

Updates from bluefin have been added:

• Flatpaks are installed/removed all at once, instead of looped one-by-one
• Flatpak setup restarts if flatpak install fails
• Fedora flatpaks are explicitly removed
• GNOME Software quits before running fedora-third-party commands

Fixes and updates to repo configuration:

• If repo-info.yml already exists, it won't be overwritten by subsequent usages of the module
• If a repo isn't configured, Flathub is used as the default
• README changes to explain the above

[zelikos]

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.