Don't write configuration in ~/.config/containers; only read them

[debarshiray]

/kind bug

Description

One of the bigger pain points of the Cgroups v2 migration was the presence of runtime="runc" in ~/.config/containers/libpod.conf. In the past we had a bug where ~/.config/containers/storage.conf could get corrupted, creating all sorts of confusion.

Dumping default values into configuration files in $HOME locks the user into a specific software version. There's no clean way to update the defaults along with the software because operating system updates are not meant to touch $HOME.

If we do want to create these files as guidelines for users, then everything should be commented out, as if the file doesn't exist; but then we have to maintain code that writes the files, as opposed to just reading them. It seems easier to just let humans do the writing, and document it in a manual.

Ideally all the defaults should be embedded in code, and it should be able to work without any configuration at all on a sanely set up environment. If we ship any configuration, to aid the code because it cannot auto-detect something or as vendor configuration, then it should only be in one of the OS-controlled locations. Ideally, this should be in /usr (eg., /usr/share/zoneinfo, /usr/lib/sysctl.d, etc.) but the current /etc/containers is fine for the purpose of this issue.

[mheon]

@vrothberg is looking into rewriting our configuration-handling logic to allow this.

Current thinking is that we will still write a config file, but it will only contain paths for c/storage and Libpod; everything else will be sourced from the root defaults.

[QuLogic]

This looks a bit like #3658.

[mheon]

@vrothberg I think your latest PR fixes this?

[vrothberg]

Yes, Podman is not auto-generating it anymore.