search

raspberrypi / bookworm-feedback

15 stars 1 forks source link

Policy for configuration files #400

Closed hackerb9 closed 1 month ago

hackerb9 commented 1 month ago

Sidenotes

 The following considerations are less important, but related: 1. It seems like a bad idea to have a system script which writes into user directories, obliterating any customization the user may have previously set up. Wouldn't it make more sense to modify `/etc/xdg/labwc/environment` to change the system defaults? It would also seem a lot simpler than looping over all the home directories. 1. Modifying labwc's config files, whether in the user or system directories, is not an ideal solution as doing so requires the Raspberry Pi owner to know a hidden extra step is needed after modifying /etc/default/keyboard. 1. The best solution is to patch labwc to read /etc/default/keyboard in addition to its own config files. 2. If that is not possible, please consider adding a note in /etc/default/keyboard letting people know to re-run `dpkg-reconfigure raspberrypi-ui-mods` after making changes.
> As for your other points, I don't believe there is an ideal solution to this problem - in the past we did address this by editing the files in /etc, but this then made it more awkward when we needed to make changes to those files that we wanted to apply to all users, and that is still a likely contingency as labwc is under active development. On balance, for now I think it is better to remain with the system we are currently using, but I will keep this under review for a future change. _Originally posted by @spl237 in [#392](https://github.com/raspberrypi/bookworm-feedback/issues/392#issuecomment-2768948039)_

I would like to suggest the eventual creation of a policy on how Raspberry Pi OS will handle configuration files in the future.

In particular, the current situation where a package's install script can replace every user's personal preferences in each user's home directory should be addressed. In my humble opinion, it is a mistake. It prevents users from being able to have lasting changes. Also, some apps, like labwc, do not check the system config files (in /etc) if a personal config file is found (in $HOME). The reasonable presumption is the file exists because the user created it to override the system defaults.

The question is, if not by modifying every user's config file, how can Raspberry Pi OS Devs make changes they want to apply to all users? It's not an easy problem, but it has been tackled by others and it may make sense to look at historical practice.

I believe there are (at least) four main actors who might want to write to configuration files:

  1. User. The person running the software; most impacted by choices, least level of expertise.
  2. Admin. The system administrator (root) in charge of choices that affect all users on a single machine (e.g., keyboard layout). On Raspberry Pi OS this is usually presumed to be the same as the user.
  3. OS Devs. The folks who choose the defaults for anyone who downloads a distribution.
  4. App Devs. The people who write programs like labwc that need to be configurable by any of the above and fallback to sane defaults.

UNIX has traditionally followed a scheme formalized in the Linux Filesystem Hierarchy Standard:

Debian (dpkg) handles config files in /etc specially because there could be a conflict during an upgrade if a file has been modified by the local Admin and a newer version from the Devs is available. Debian stops the upgrade and asks the Admin how to resolve the situation, defaulting to keeping the current config file. This gives the Admin the chance to merge recent updates with the local system's preferences.

This is not a desirable situation, so Debian often will allow Admins to put only the preferences they've changed inside a directory (/etc/foo.conf.d) instead of editing a single, monolithic config file (/etc/foo.conf).

So, if Raspberry Pi OS wanted to change an app's defaults in an update, they would modify only the system configuration file in /etc. Typically, only an expert user would create a personal config file in $HOME. That means the app will use the system default for nearly everyone. (Experts presumably know what they are doing and can figure it out if it breaks.)

Labwc, in particular, automatically uses the config file in /etc if no personal config file exists in $HOME. Unfortunately, personal configs are currently sure to exist, due to the automated creation by raspberry-pi-uimods. I suggest modifying the install script to remove automatically generated config files so labwc can once again use /etc/xdg/labwc/labwc.conf.

lurch commented 1 month ago

A couple of "subtleties" that immediately spring to mind:

But I'm sure that Simon has already thought about all of this in much more depth than I have... 😉

hackerb9 commented 1 month ago

A couple of "subtleties" that immediately spring to mind:

  • You mention that some applications ignore any settings in /etc if there's a user-specific config file in $HOME. However I believe there might be some applications which merge any user-specific config "on top of" the settings in /etc?

That is correct. And some config files can reference others, so a user doesn't start from scratch when overriding a single setting.

However, I was not thinking of apps that can merge config files as being a potential problem: there would be no temptation for RPi OS to write to the user's home directory if changes can be made in /etc.

  • It's not always immediately obvious which things are "system level" settings, and which things are "user level" settings? e.g. you've asserted that the keyboard layout is a system-level thing; but if there are multiple users on the Pi, one user might want their locale settings set to French and another might want them set to Spanish? (and of course things like the Desktop background will always be user-specific)

Thank you for pointing out that ambiguity. Settings do not typically belong to a single level. If a more local level setting exists, it overrides a global default.

Imagine a Hungarian developer who writes an app that defaults to her locale, RPi OS packages it in a way that sets the default to "UK", the admin of a Pi 500 at a school overrides the system default to US, and a teacher chooses Japanese for his account on the Pi. There is no conflict since the settings have a clear priority order. Other teachers may accept the system default (in /etc) or, since each account has its own home directory, make their own individual choices of French, Spanish, or what-have-you.

But I'm sure that Simon has already thought about all of this in much more depth than I have... 😉

Indeed, I am surely not saying anything new. My hope is merely to put thought into words so policy can be made explicitly instead of on an ad hoc basis.

lurch commented 1 month ago

there would be no temptation for RPi OS to write to the user's home directory if changes can be made in /etc.

I'm not sure what you mean by this? To my mind, "RPi OS" includes both the system-level packages like the raspberrypi-ui-mods you've mentioned, but also the user-level packages like raspi config, "Appearance Settings", "Screen Configuration", "Raspberry Pi Configuration" etc. And some of those things (e.g. the "Interfaces" tab in "Raspberry Pi Configuration") are definitely a system-level setting, whereas others (e.g. the "Desktop" tab in "Appearance Settings") are definitely a user-level setting, and some things might be somewhere inbetween?

I'm not disagreeing with anything you're saying, I'm just pointing out that this can all be quite complex and not have a "single obvious solution" ? 🤔

Imagine a Hungarian developer who writes an app that defaults to her locale, RPi OS packages it in a way that sets the default to "UK", the admin of a Pi 500 at a school overrides the system default to US, and a teacher chooses Japanese for his account on the Pi.

And herein lies another "subtlety" - as you've pointed out, a lot of Raspberry Pi setups are single-user, in which case the "User" and the "Admin" are the same person. And Raspberry Pi OS obviously has to be very beginner-friendly, so most people might not even realise that "system level config" and "user level config" are two different things - they expect everything to "just work". And so somehow we have to balance this requirement with also offering the ability to cater to more advanced / complex setups, e.g. the "multi-user Pi in a school setup" example that you provided 😉

spl237 commented 1 month ago

There is already a "policy" about this, but I suspect it will not be one with which you are happy. It is, however, one that has been in effect for ten years or so, so is unlikely to be changed.

Desktop users should not, in general, be editing configuration files by hand. We provide GUI tools - Appearance Settings, Raspberry Pi Configuration, Mouse & Keyboard Settings, Screen Configuration etc - which can make any configuration changes which the vast majority of users would need, and these tools are all written so that conflicts will not arise. If the only way configuration files are written is using these tools, then there should be no problems involving configuration files. This fits with the way modern desktop GUIs work - in commercial environments like Windows and MacOS, it is very rare that a user should be hand-editing a config file.

If a user decides that for some reason they wish to edit files by hand - and I will admit there are users with specific circumstances where that might be necessary - then we can no longer guarantee that there will not be issues if hand-edited files are subsequently operated on by the GUI tools. We make all reasonable efforts to avoid overwriting user configuration, but simply because of the sheer range of things a user might change, if you have started hand-editing files, our advice would be that you continue to edit those files by hand. (And indeed, if you have the knowledge to hand-edit files, then you should also be sufficiently competent to be able to correct any problems which might arise in said files. Incidentally, if you are hand-editing files, you are almost certainly using features which we do not officially support anyway!)

As above - we already make best efforts to avoid overwriting user config, but there are circumstances where, because we need to push out changes to all existing images, it is unavoidable that it will happen for some users. I don't see that a formal policy would make any real difference to this, so I am reluctant to establish one.