On Wed, Feb 15, 2023 at 07:50:10AM -0800, Russ Allbery wrote: > Well, I adore this way of configuring things and think it's way better > than how Debian has been doing it and I haven't used Red Hat since the > late 1990s, so *shrug*. :) > > But the point wasn't to advocate for that approach specifically, only that > if you *do* have configuration that the user is not allowed to change > because the package is going to override it, it needs to not be in /etc, > because if it's in /etc it's going to be really confusing. I don't care > where you put it, but /usr is the logical spot? > > I think your argument is that maybe you shouldn't have a bunch of > configuration the user can't change, and I agree!
I think, making a parallel, that there has been since forever a bunch of configuration the user couldn't change, namely the default configuration values embeded in code, and since before the existance of RedHat itself it was in /usr The way I see it, now it is sometimes being made explicit by storing it in human-readable config files instead of code, which is great because I can go and see what the defaults are and override in /etc only what I need to override. A well documented default configuration in /usr is a better interface for me than default values hidden in documentation that risk going out of sync with code. Along this parallel, one useful point I'd make an effort to extract from Marc's rant is that changes of configuration in /usr need to be treated like changes in default values for configuration in code: that is, as interface breaking changes, which users need to be aware of, and need to be convered in upgrading documentation as would any other behavioural change that may break existing configured systems. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
