Ensure that all user-overridden configs are handled correctly

[m-roberts]

postinst - for each user config override

• Copy into /etc/skel?
• Ensure that it is always handled correctly - i.e.

e.g.

.config/
    lxterminal
    systemd/user

[m-roberts]

@benp44

TLDR: Main question here is - do we care about user config overrides, and how should we handle them now?

The OS is now using global config files for the following: lxpanel, lxsession, openbox, pcmanfm

What these have in common are their LXDE-pt session-specific file paths. lxterminal and compton do not have any such thing - their file paths are /usr/share/lxterminal/lxterminal.conf and similar, and are owned by their relevant Debian packages. That is, changing this file for our own formatting would mean that it would be overwritten. Any Debian package would conflict.

The question I have is: can we avoid copying system config files to the user that do not have a session? Is this even much of an issue?

Everything else seems to have worked out fine in transition, on the surface, at least.

Beyond that, one other question I had while going through this was that we seemed to attempt to create lxterminal config file for root - did we need this for anything in particular? When would this be used?

[benp44]

@m-roberts we covered this during the call right - I think we need to investigate what Raspbian are doing when the system-level files are modified.

[m-roberts]

@benp44 That's right. Here are my notes on system-level config files, which likely broadens the scope of this ticket. Either we need to update this ticket to reflect what is captured here, or break out into separate tickets.

Evaluate if system-level configuration files should be blindly overwritten or if the user should have the option to decide what to do with it
    pt-update/postinst

    NOTE: Settings application is going to overwrite these files

    How does Raspbian (e.g. rc_gui) deal with modifying configuration files? What about user files?

    What does the GUI updater do in this situation?
    Can we improve the way this is presented to the user?

[m-roberts]

One other bonus thing to consider:

Because we are using system-level config files now, we could move away from User=pi systemd services which use GUIs and commit to moving everything into autostart file, given that it would be easy for us to update that if we wanted to later.

This is dependent on if we can get away with just being system-level - as flagged in earlier comments, this needs more investigation.

[m-roberts]

MIKE https://github.com/RPi-Distro/raspberrypi-ui-mods/blob/master/debian/raspberrypi-ui-mods.postinst#L105 To apply the updates, please reboot your Pi, and then select one of the options on the Defaults page in Appearance Settings. clicking a default option in pipanel creates default local configs with default hardcoded values

BEN Nasty

MIKE yeah

BEN I'd be tempted to keep things as they were, I mean it was working fine But then I can't think of a scenario in which their new way of doing things will clash with ours - can you?

MIKE pipanel isn’t even on our OS

BEN yeah right

MIKE we can do what we want i think that having the settings app copy the global and then modify seems reasonable fuck hardcoded values

BEN yeah def

MIKE let’s roll with that, then

BEN Not copy to ~ when user is created?

MIKE we can still use pt-ui-mods to control updating config files if needed but for the most part, i think we want to try and step back from that (edited) i guess i meant copy from global if it doesn’t exist and always modify that

BEN Thing is it may not be only pt-settings that will modify these things, so we can't rely on that doing the copy

MIKE i kinda like the idea of using global if you don’t change anything, and then only override what you want what else would modify it?

BEN Some other config application, or the application itself (e.g. users can edit the panel, or the terminal settings from config GUIs within those apps) (edited)

MIKE we’ve removed all of the other config applications well, links to them

BEN Right click on panel and edit?

MIKE hmm, wonder what file that uses

BEN Right click on lxterminal window and "Preferences"

MIKE :thinking_face: more investigation required there then

BEN I would be tempted to pull the plug - just go back to what we had before because that worked fine Ignore raspberry pi's weird approach It's an attempt to try and lock things down, which is really going against the grain of the way these applications were designed. Not only does it seem undesirable from a user perspective, but may well be at best error-prone (at worst impossible) from a tech/maintenance perspective I think they sewed the seeds of this when they first started hard-coding stuff into pipanel. Now rather than cleaning that up and unpicking the sunken cost, they're just chasing it down a rabbit hole. (Too many metaphors?)

[m-roberts]

Question: what does lxappearance do? Forget what RPi are doing.

[ItsChoudhry]

Based on our discussion I will be testing if a partially set config file(e.g. not all setting are present) is found in the user directory does it take the user settings then fill in the rest from the system level.

Notes form the meeting:

Can we only override settings that user specifically wants in the user config directory?
    i.e. fall back onto system-wide configuration for everything else, minimising impact of "upstream" changes

    if not
        We need to copy the entire config contents
            We probably need to notify the user that there are new defaults

[mikael-bark]

If Choudry finds that we can not partially override system configs we have the following suggestion given by Mike that would solve it: We could store any setting that has been specifically set by the user in a "delta" file somewhere outside of the normal config directories. This delta config can be used together with the system level config file to create an ad hoc user local config file that copies the system level settings and just overrides those settings specified in the delta config.

The benefit would be that we could mirror some of the system wide changes made to the system config in our user config without affecting the changes made by the user in the pt-settings app. And if changes are detected in the system config we can automatically apply them.

The examples below outline how the files could look:

SYSTEM.conf, if updated notify user of new defaults

setting1=bla2
setting2=la2
setting3=de2
setting4=lala2

USER.conf

setting1=bla2
setting2=la2
setting3=de2
setting4=NEWVALUE

USER DELTA

version_last_applied=1.20190220
setting4=NEWVALUE

[mikael-bark]

I'm working on investegating how lxappearance handles the config files. Specifically to answer the following two questions: What if there are no user config files: Does it copy these over as required? Does it only add overrides for specified settings?

[ItsChoudhry]

It's weird I made a pcmanfm.conf in the ~/.config/pcmanfm/LXDE-pt/ with only 2 setting

show_hidden=1
columns=size;name;mtime

then I rebooted and checked the file and it was the same as before reboot which is expected, but after opening the file manager I checked the file again it added all the setting my one was missing. So it matches the one as seen here, but with my changes.

[ItsChoudhry]

After further testing with another config file I tried to override etc/xdg/lxpanel/LXDE-pi/panels/panel and if it does not contain all the setting it doesn't work so it's not mixing and matching the settings. I had only 1 setting in the user version

Global{
    edge=top
}

After rebooting I just have black bar at the top of the screen.

[m-roberts]

@ItsChoudhry I don't think that we can do deltas for lxpanel - a deep copy and modify will be needed, as order of parts and selected shortcut icons need to be captured in the file in its entirety. Hadn't thought about this, so good catch

[mikael-bark]

My investigation tells me that lxappearance seem to create new local configs without regards to the system configs. i.e. it seems like they might be hard coded somewhere.