refactor(default-flatpaks): Support multiple repos

[jonerrr]

Currently, there is no way to install flatpaks from multiple repos. If you specify multiple default-flatpak sections in your recipe.yml, only the last one will be used. One way to fix this is by changing the repo-url key to accept an array of repos instead of just one, so users would only need a single default-flatpaks section for all their repos.

[jonerrr]

Here is my idea for the format:

   - type: default-flatpaks
     notify: true
     system:
       gnome-nightly: 
          url: https://nightly.gnome.org/gnome-nightly.flatpakrepo
          install:
           - org.gnome.Ptyxis.Devel
       flathub:
          url: https://dl.flathub.org/repo/flathub.flatpakrepo
          install:
            - org.mozilla.firefox

The key (in this example its flathub and gnome-nightly) will become the name of the flatpak repo. If no URL is specified, the default will be flathub.

[xynydev]

Let me just brainstorm here real quick:

# recipe.yml
modules:
  - type: default-flatpaks # install flatpaks from a specified repo
    notify: true # optional, default: false
    scope: system # or user, both for installs and repo
    #  repo: # if this section is omitted, flathub is used by default
    #       url: https://dl.flathub.org/repo/flathub.flatpakrepo           
    #       name: flathub
    #       title: Flathub (system)
    install: # installed from the repo specified above, or flathub if not specified
        - org.gnome.Loupe
    # remove: # backwards-compatibility, may remove flatpak regardless of repository
  - type: default-flatpaks # install flatpaks from a specified repo
    notify: false
    scope: user
    install: # installed from flathub
        - org.kde.kdenlive

Transformed into

# /usr/share/bluebuild/default-flatpaks/configuration.yml
- notify: true
  scope: system
  install:
      - org.gnome.Loupe
- notify: false
  scope: user
  install:
      - org.kde.kdenlive

Which is iterated by the script ran by systemd. If necessary, configuration.yml could be split into multiple files based on the scope. Without the repo refactor, this could remain backwards-compatible. Maybe we could support both?

[fiftydinar]

It also needs to be thought about on how to not break existing configs in /etc/bluebuild/default-flatpaks/ for local-users, while migrating them to new yml config at the same time.

[xynydev]

Ok, with the new structure I proposed above I don't see a way we could keep local user configs as we do now. I don't know how many people use those, but I've never heard of anyone using them. Maybe we could provide a way to disable the service units, maybe a systemctl command in the docs would do?

I can't really picture a way we could support both local configuration and multiple configuration options for different repositories etc. effectively. IMO giving up local configs is a worthy trade-off, as this is supposed to be a part of system configuration. I'm not even sure about keeping the whole remove-section. We should really just strive towards not recommending widespread usage of this module on public images, and steering towards refactored Yafti, or at least including documentation for disabling the Flatpak install.

[fiftydinar]

I don't know how many people use those, but I've never heard of anyone using them.

I didn't heard of anyone using local configs either, but it becomes useful when someone really needs it.

I can't really picture a way we could support both local configuration and multiple configuration options for different repositories etc. effectively. IMO giving up local configs is a worthy trade-off, as this is supposed to be a part of system configuration.

Maybe it's possible by strictly specifying repo URL & remote name in local-user config, to prevent this case in new local configs. If repo doesn't exist, add it & install flatpaks from that remote name.

Old local configs would be invalid unfortunately, so some transition steps would be needed for local-users who utilized local config.

But, this is maybe not enough & some more complex checks are needed.
It's also another maintenance burden, to assure that everything would work correctly.

I'm not even sure about keeping the whole remove-section. We should really just strive towards not recommending widespread usage of this module on public images, and steering towards refactored Yafti, or at least including documentation for disabling the Flatpak install.

Well, I think that refactored yafti & default-flatpaks will be still different.
yafti is not the automatic setup like default-flatpaks is, it's the setup that requires manual input from the user.

Bundling flatpaks inside ISO is possible, but it's still not enough to account all usecases, especially when image-maintainer intends to update flatpak list/repo or when local-user is rebasing to the image which utilizes default-flatpaks.

So default-flatpaks module is still useful & fills some gap.

But I agree that module is not in the ideal state & maybe refactored yafti can actually help in this once it's done.

[xynydev]

Bundling flatpaks inside ISO is possible, but it's still not enough to account all usecases, especially when image-maintainer intends to update flatpak list/repo or when local-user is rebasing to the image which utilizes default-flatpaks.

So default-flatpaks module is still useful & fills some gap.

Yeah, totally. In public images default-flatpaks should be used to add essential flatpaks, which should also be baked into the ISO. Yafti or a similar approach would be better for non-essential flatpaks, and installing them would be optional. Providing a way for the user to disable default-flatpaks would of course be necessary still.

Maybe it's possible by strictly specifying repo URL & remote name in local-user config, to prevent this case in new local configs. If repo doesn't exist, add it & install flatpaks from that remote name.

Old local configs would be invalid unfortunately, so some transition steps would be needed for local-users who utilized local config.

But, this is maybe not enough & some more complex checks are needed.
It's also another maintenance burden, to assure that everything would work correctly.

These are the reasons I'd opt for just removing support for local configuration.

One last way I could see working is just to write the flatpak list in /usr/etc/bluebuild/default-flatpaks.yml or whatever, but read it from /etc/. This would effectively allow a local user to replace the maintainers configuration with something else entirely. But this would only work on atomic Fedora, and would be basically the same as the user just disabling the module entirely.