Re: Configuration files, local changes, and "managed section" markers
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 <enrico@enricozini.org>
Reply to: