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.

[fiftydinar]

I came up with this recipe, as I don't find the above recipes ideal:

notify: true
system:
  - repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
    repo-name: flathub-system
    repo-title: "Flathub (System)"
    install-apps:
      - sadasd.sf
      - rtrsfgfg.sd
    remove-apps:
      - dfsf.ft
      - rtwtert.ty
  - repo-url: https://dl.something.org/repo/something.flatpakrepo
    repo-name: something-system
    repo-title: "Something (System)"
    install-apps:
      - application 1
      - application 2
    remove-apps:
      - removal 1
      - removal 2

user:
  - repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
    repo-name: flathub-system-2
    repo-title: "Flathub (System-2)"
    install-apps:
      - uythj.sf
      - fguy.sd
    remove-apps:
      - sfvcvx
      - sfbvcbcbd.ty

What are your opinions?

[xynydev]

I feel like we should keep the nested repo structure, and the -apps postfix seems redundant, and if we end up supporting installing runtimes etc. in the future, it would be redundant.

One thing I'm also not sure about is the removal being right next to installation and where the repo is declared, when in reality it can remove flatpaks from any repo. Maybe it could be lifted to be at the same level as user: and system: and have a warning attached (since adding a flatpak to remove: will make it very annoying to try to use).

[fiftydinar]

I feel like we should keep the nested repo structure

Hmm, I don't know how would I include that while making it possible to define multiple repos in 1 module recipe call.

The -apps postfix seems redundant, and if we end up supporting installing runtimes etc. in the future, it would be redundant.

Agree, install/remove is better in this case.

One thing I'm also not sure about is the removal being right next to installation and where the repo is declared, when in reality it can remove flatpaks from any repo.

I thought of including it in case user has installed 2 same application from different repos. But I don't know if that's possible, as I don't see in flatpak uninstall --help the option for specifying remote. So yeah, I guess it can be moved.

[xynydev]

Ok, so:

notify: true
system:
  - repo:
        url: https://dl.flathub.org/repo/flathub.flatpakrepo
        name: flathub-system
        title: "Flathub (System)"
    install:
      - sadasd.sf
      - rtrsfgfg.sd
  - repo:
        url: https://dl.something.org/repo/something.flatpakrepo
        name: something-system
        title: "Something (System)"
     install:
      - application 1
      - application 2

# and the same thing for user: here

I just realized that remove: couldn't be top-level since it would still be either a user or system flatpak that is removed... This brings me back to my previous idea where instead of system: and user: keys we just have one scope: key to specify whether to install the flatpaks as user or system flatpaks. What's the use case for installing both user and system flatpaks anyways? (though to be clear, my earlier idea would still support that)

[fiftydinar]

@xynydev This recipe does look better.

What's the use case for installing both user and system flatpaks anyways?

I am this usecase.

I install system flatpaks as essential applications, which will be used by all users. User flatpaks are installed as name says, for users only, because not all users would want Minecraft installed f.e.

So it's for multi-user setup.

With scope key, you would need to have 2 module calls to achieve this, while with system & user dropdown, you only need 1 module call

[xynydev]

User flatpaks are installed as name says, for users only, because not all users would want Minecraft installed f.e.

But if the user flatpaks are in the image, they are installed for all users anyways, no?

[fiftydinar]

But if the user flatpaks are in the image, they are installed for all users anyways, no?

You're right, yes, I see now.

So I guess that we can go with the scope key

[xynydev]

Might want to investigate how this works. The dev is friendly too. https://codeberg.org/HeliumOS/flatpak-readonlyroot

[fiftydinar]

It seems that tool invokes classic flatpak install & flatpak remote-add in a container.

I don't like this part:

The main downside of this approach is the increased filesize. e.g. platform dependencies are not shared between the flatpak-readonlyroot installation and the typical flatpak installations

But I like this part:

oh, so they only update on image build?

Yes, the flatpaks are completely managed by the mechanism that delivers /usr instead of flatpak's package management

Great for flatpaks which you don't want user to uninstall. But don't know where the data is stored for those flatpaks.

But, all of this is an unsupported behavior & I'm not comfortable with that. It can get unsupported in the future.