[Feature Discussion] Declarative Flatpak Configuration?

Development
1

Hi everyone!

I am participating in Google Summer of Code, where we contribute to open-source projects. I proposed to Flatpak syncing between machines and I want to get your opinions on how this problem hurts you and could this solution be helpful. What do you think about this project? How could this solution improve your user experience?

P.s. If topic is not related to NixOS community, then you can delete this topic

1 Like
2

It’s the only non-declarative part of my systems at the moment, so I care a lot about this. Not just syncing applications, mind you, the application-specific overrides and other settings are important too.

I’ve thought about a solution to this in the past, this is also roughly what I came up with, except of course said list would be synced by writing it to a well-known path (e.g. $HOME/.config/flatpak/apps or such) and the daemon could pick up changes from there. Ideally it would also listen for prods on a UNIX socket so that whatever syncs the file can say “hey, I’ve updated the list, check if you need to do anything”.

I think it’s important that such a tool would not rely on cloud services (or github gists), so that its information source could be supplied by whatever mechanism people already have in place for file syncing. It makes it less complicated too if it doesn’t need to handle all the thousands of cloud storage, gist, pastebin and whatnot protocols out there.

I think it’s also important that the application list is in a format accessible to tools (toml, yaml, json, whatnot), and includes the overrides you set. That way, at least with nix, I can properly write the system-specific filesystem access overrides I need. No idea how to properly do this with other sync tools, it’s why I use nix. Perhaps allow reading multiple files, and only sync specific ones based on use case?

Obviously I’d find it really cool if someone started on this :slight_smile: Would love to help out/test.

The benefits to me are clear: when install a new system (or reinstall my current one because I borked it…), all my applications move with me. I no longer need to fear getting a fresh system, or dread restoring a backup that will take me weeks.

As-written, the proposed project may not fit well within this particular ecosystem though.

2 Likes
3

There are multiple options of how Flatpak could be managed:

  1. Divergent mode: /var/lib/flatpak/repo is fully under control of flatpak, Nix only makes flatpak available on PATH and systemd aware of the services. This is the only mode of operation currently supported.
  2. Convergent mode: There is a list of software to be installed and when a program is executed, the repo will be modified accordingly.
    • NixOS could run the program as a hook during system activation. Though that would likely slow the activation down significantly and make the system less congruent as a whole.
  3. Congruent mode: There is a list of software with sufficient detail that the state of the Flatpak OSTree repo can be recreated from it.
    • NixOS could generate the OSTree repo as a part of building the system.

Read more about Classification of system management methods.

Goal of NixOS is congruent system management but it does not require you to manage everything (for example, having it manage the content of RDBMS would likely be less convenient than the benefits it would bring) so your proposal would not really conflict with it.

Your proposal could be either convergent or congruent, depending on the details.

4

I think a congruent model for flatpak is close to impossible. There is some (presumably complex) logic to get dependencies specific to the graphics driver you’re using, which means that for any given flatpak different systems will need different data. This would be difficult to get usable UX for in the nix world.

Hence I think a convergent model (and ideally one with a system service as proposed here so that rebuilds don’t take long) makes the most sense for better integration.