use remotes.d path/files to configure default flatpak remotes

@jane400 pointed out in !4756 (closed) that we can use remotes.d to configure flatpak remotes instead of adding them manually in a post-install, this is a MUCH better mechanism that I hadn't know about until her comment :)

https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-remote

System-wide remotes can be statically preconfigured by dropping flatpakref files into /etc/flatpak/remotes.d/.

added help wanted label

Unfortunately we already know that putting this kind of data under /etc is a mistake. So hopefully there's also a mechanism to do it under /usr. If not, hopefully they'll welcome a patch upstream.

By Pablo Correa Gomez on 2024-02-12T18:55:59

maybe this isn't a bad thing... if a user wants to disable or change the default remote, how would they do it if it was configured under /usr ?

By clayton craft on 2024-02-12T18:55:59

The default remote can be changed with priorities I guess? Though removing it might be a good point, it can always we done with apk add !postmarkeos-base-ui-flatpak, can't it? The problem I have with /etc is that if some user ever touches it, and we are in the situation of having to update the gpg key, then it won't be updated on the user side. Am I going a bit too paranoic here?

By Pablo Correa Gomez on 2024-02-12T20:14:28

Pablo Correa Gomez commented on a discussion: #2596 (comment 1769696136)

The default remote can be changed with priorities I guess? Though removing it might be a good point, it can always we done with apk add !postmarkeos-base-ui-flatpak, no?

Yeah, technically that's an option. But later if we decide to add anything else to that subpackage (e.g. preloading runtimes) then this option becomes less than ideal.

The problem I have with /etc is that if some user ever touches it, and we are in the situation of having to update the gpg key, then it won't be updated on the user side. Am I going a bit too paranoic here?

Oh wow, yeah that's a good example of why we'd want to maintain this in /usr. Also, there is an option in the config (xa.disable), and if flatpak is patches to allow overrides from /etc to the config in /usr, then this option could be used to disable the default remote quite easily (make a duplicate entry in /etc and set that config to true?)

Ok, sounds like we need to propose a patch to upstream?

...

On Mon, 12 Feb 2024 20:14:13 +0000 "Pablo Correa Gomez (@pabloyoyoista)" gitlab@mg.gitlab.com wrote:

By clayton craft on 2024-02-12T22:35:54

Also, there is an option in the config (xa.disable),

This is pretty handy :D

Ok, sounds like we need to propose a patch to upstream?

Sadly seems like so 😢

By Pablo Correa Gomez on 2024-02-12T23:37:32

There we go: https://github.com/flatpak/flatpak/pull/5688

By Pablo Correa Gomez on 2024-02-14T00:22:15

mentioned in merge request !4756 (closed)

By clayton craft on 2024-02-12T18:54:53

mentioned in merge request pmbootstrap!2254 (closed)

By Pablo Correa Gomez on 2024-02-16T10:28:59

changed due date to November 30, 2024

By Pablo Correa Gomez on 2024-09-23T14:04:48

It took 7 months, but this is finally upstream! Hopefully 1.16.0 is not far, so setting the deadline to November 30th

By Pablo Correa Gomez on 2024-09-23T14:05:10

changed due date to February 15, 2025

flatpak 1.16 is now in Alpine! So we could do this too!

mentioned in commit 4d4fc992

mentioned in merge request !6119 (merged)

mentioned in commit b0daad09

closed with merge request !6119 (merged)