Hi, On Sat, Jul 27, Mathias Homann wrote:

OK, let's pretend we do it, and have the distro-supplied defaults in /usr/etc and only local changes in /etc.

Today we have distro-supplied defaults below /usr/lib and the local changes for this apps in /etc.

let's also pretend there is an app that has one file that used to sit in /etc/ and is named /etc/apprc.

It would be simple enough to patch the app to read /usr/etc/apprc instead of / etc/apprc, but what about those local changes?

We'd have to patch the app to read /etc/apprc and only if that doesn't work read /usr/etc/apprc, right?

Depends on how this app reads the configuration files.

what about this scenario: /usr/etc/apprc defines several variables, let's say foo and bar. local admin wants to change only one of them, so he creates /etc/ apprc and put "foo=123" in it.

...how would the app get the value for bar?

Like all the applications who are doing this today already? And there are many. Only look in /usr/lib for all this configuration files nobody ever finds ...

So actually, we would have to patch the app to **first** read /usr/etc/apprc and then read /etc/apprc if it exists and overwrite all variables found therein with the values therein... or in other words: app startup takes longer, worst case: twice as long.

Nobody ever noticed this with all the apps doing this already today.

Now imagine it is not a "userspace" app but a service that gets started on demand, for example each time something connects to ... lets say port 21.

Nobody ever noticed this with all the apps doing this already today.

doen't sound all that good to me anymore.

You would be right if we would introduce something new. But as you can read in my document, many apps are doing this already today, including systemd, PAM, sysctl, module loading and many, many more. There are also libraries which do this more or less transparent for the app. In many cases, we only need to make use of it. And: this will come. The systemd people want this, too, and are creating bug reports to upstream projects that they should change their code. So the only question is: do we want that this happens in a chaotic way, and people have to search in 200 places for the configuration files, as every application uses it's own solution, or do we want to drive this in a more consistent and planned way? Thorsten

Am Freitag, 26. Juli 2019, 19:39:57 CEST schrieb Thorsten Kukuk:

...

On Fri, Jul 26, Bernhard Voelker wrote:

...

On 7/26/19 2:18 PM, Thorsten Kukuk wrote:

...

to come back to this, original email as reference below. Looks like Lennart Poettering wants to do something similar with Fedora for systemd.volatile, /etc should only contain the user modified files, everything distribution provided should be located in /usr.

I only don't like to fill up /usr/lib with even more stuff people will not find anymore afterwards.

The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc

Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.

What's the opinion here?

If we do want to follow Poettering and Fedora, then to me it would sound logical to at least go the same direction (together with Fedora?).

No, we don't want to follow Poettering and Fedora, especially not, if they move everything to /usr/lib. While we share the same idea, but to solve complelty different problems, we hope we can convience them to follow us and put the configuration files in an own directory.

/usr/lib is already overcrowded and you cannot really search/grep there for something. The clear feedback I got until now, especially at the openSUSE Conference, was, please make sure that the configuration files are back in one, or at least two locations and not in several hundred ones.

...

BTW: is there a list of affected packages available? That can't be too long, is it?

rpm -qf /etc/* /etc/*/* | sort -u

The list is long, some of them are low hanging fuits, others will be next to impossible to solve. That's why I'm interested in what Lennart is planing, it could save us quite some work.

Thorsten

*Mathias Homann* Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@eregion.de[1] LinkedIn: http://de.linkedin.com/in/mathiashomann/[2] *gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102*

-------- [1] mailto:Mathias.Homann@eregion.de [2] http://de.linkedin.com/in/mathiashomann/

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org