dir: search for repositories also under FLATPAK_BASEDIR #5688
Conversation
|
I guess the auto macros in |
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
from
2529d63
to
a6af22f
Compare
|
GLib 2.46 is the current latest supported. |
en_GB: I think you mean "Most notably" |
All of |
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
3 times, most recently
from
582f01e
to
f2e16b5
Compare
Is that a policy? But I'm not a native speaker, so just fixed it.
Actually, that makes total sense. I updated using GPtrArray. I'm not very used to it, so hope I did it right (second try after debugging a segfault) |
There was a problem hiding this comment.
This seems like a reasonable addition, but I'm wondering whether we need to properly support /etc-overrides-/usr here. Currently, if a distro ships a .flatpakrepo in /etc, an admin who doesn't want it can just remove it before booting the system.
With a remote defined in /usr, a same-named .flatpakrepo file in /etc would be applied over top of the one in /usr (when both are discovered at the same time), but (AFAICT) there would be no way to cancel the repo addition, or even disable it. The admin could of course flatpak remote-delete it from the booted system, which is fine for a typical user, but maybe there's a case where that wouldn't be ideal?
This was our initial expectation downstream. Our thought there, is that the admin can simply instead create a file under /etc with a repo with the same name and |
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
from
f2e16b5
to
0f94b47
Compare
|
This should be ready for another round of reviews. Hopefully closer to being merged now :) |
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
2 times, most recently
from
75b778b
to
b2e7171
Compare
|
Rebased and amended the documentation, stating that one file will take precedence over the other, but not mentioning merging (since that does not happen) |
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
from
b2e7171
to
a398ec4
Compare
|
Fixed comments! |
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
from
a398ec4
to
b2e5f98
Compare
|
Rebased without any other changes |
conf_dir vs. config_dir tell us nothing. conf_dir vs. conf_dir_str is certainly more clear.
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
from
b2e5f98
to
1445410
Compare
|
Rebased without any other changes. Is there anything else I can do to help move this forward? |
This a preparatory commit for the follow-up changes, where we will be looking at more directories.
This is more compliant with FHS specification. Most notably, /etc is not appropriate to hold distro configuration, which is a common use for the remotes.d feature. It is better practice to put things under /usr/share, and let the system administrator modify /etc to their will, of course giving them priority. Update documentation to reflect this change
pabloyoyoista
force-pushed
the
usr-remotes.d
branch
from
1445410
to
fc3ec12
Compare
|
Feedback addressed :) |
This is more compliant with FHS specification. Most remarkably, /etc
is not appropriate to hold distro configuration, which is a common
use for the remotes.d feature. It is better practice to put things
under /usr/share, and let the system administrator modify /etc to
their will, of course giving them priority.
In the process, fix a couple of leaks.
I know that FHS might not be the most up-to-date standard. But luckily the purpose of /etc hasn't really changed. FHS states:
/etc : Host-specific system configuration. So not feasible for distributions to put their configuration.