Directory structure suggestion for configuration in /etc

[Frank Guthausen]

Hello.

A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.

Every now and then it might be useful to switch changes on and off. The
Debian apache2 package uses sites-available/ and sites-enabled/ folders.
This is convenient.

I use this idea as a blueprint for administration. I put local
configuration stuff into /etc/project.available/ folders and symlinks
into /etc/project.d/ folders. This allows to toggle on/off mode easily
and is a coherent scheme (besides the little deviation in apache2).

Is it reasonable to use this idea as "best practice" and implement it
into Debian style administration recommendations? It works very well
e.g. for repository usage /etc/apt/sources.list.available/ where an
admin can look what is possible even if not part of the live system
yet. This would allow to ship a bunch of suggestions without enabling
them by default and without the need to edit the project.conf file.

Please share your thoughts with the community.
Was anything like this discussed previously?

[Marco d'Itri]

Post by Frank Guthausen
Is it reasonable to use this idea as "best practice" and implement it
into Debian style administration recommendations? It works very well

No: the expected default for systemd-managed services is to use
/etc/$SERVICE/ .

[Frank Guthausen]

On Thu, 19 Dec 2024 09:01:09 +0100

Post by Marco d'Itri
No: the expected default for systemd-managed services is to use
/etc/$SERVICE/ .

Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV

[Marc Haber]

On Thu, 19 Dec 2024 10:09:41 +0100, Frank Guthausen

Post by Frank Guthausen
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux.

Bullshit.

[Ansgar 🙀]

Hi,

Post by Frank Guthausen
On Thu, 19 Dec 2024 09:01:09 +0100

Post by Marco d'Itri
No: the expected default for systemd-managed services is to use
/etc/$SERVICE/ .

Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV

Please keep such messages to appropriate mailing lists such as the
Devuan list (aka "Debian is not GNOME first discussion list" as they
are somehow concerned about GNOME).

🐟🐠🦈,
Ansgar

[Frank Guthausen]

On Thu, 19 Dec 2024 11:00:03 +0100

Post by Ansgar 🙀

Post by Frank Guthausen
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV

Please keep such messages to appropriate mailing lists such as the
Devuan list

As long as Debian ships System-V-like init in the official
repository[1] I'm pretty sure I'm on the correct mailing list.

There is no need to assume that everything related to Debian is coupled
to systemd. It's the user's or admin's choice which init system is to
be used, regardless of Debian's decision what the default is. I can not
conclude what Devuan has got to do with this. If you want to extend the
debate to a broader auditorium, think about Debian GNU/Hurd and Debian
GNU/kFreeBSD in the first place.

If my suggestions do not apply to situations where systemd is used,
I'd suggest systemd advocates to stay quiet because the topic does
not concern them. TIA

[1] https://packages.debian.org/bookworm/sysvinit-core

[Marc Haber]

On Thu, 19 Dec 2024 12:34:57 +0100, Frank Guthausen

Post by Frank Guthausen
If my suggestions do not apply to situations where systemd is used,
I'd suggest systemd advocates to stay quiet because the topic does
not concern them

That nicely helps me to put your suggestion in the correct
compartment, which is the bin.

[Ansgar 🙀]

Hi,

Post by Frank Guthausen
On Thu, 19 Dec 2024 11:00:03 +0100

Post by Ansgar 🙀

Post by Frank Guthausen
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV 

Please keep such messages to appropriate mailing lists such as the
Devuan list

As long as Debian ships System-V-like init in the official
repository[1] I'm pretty sure I'm on the correct mailing list.

Thanks for providing another good reason to drop init scripts.

Ansgar
(hoping to eventually `dak rm sysvinit` to end this)

[Simon Richter]

Hi,

Post by Frank Guthausen
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.

It depends on the package.

Some packages have a "registry-style" configuration, where instances of
the service are configured in separate files -- but files are provided
by the admin. That is what the webservers do, because a single binary is
responsible for hosting multiple largely independent virtual hosts.

Other packages provide an actual registry, like systemd or dbus, so they
need a mechanism to collect configuration files provided by other
packages from a directory.

For many packages, either of these is overkill, and the deviation from
upstream causes more work than it saves.

The conffile mechanism in dpkg acts like other version control systems
here and will ask the user to resolve if two branches (new defaults and
local configuration) of a file both have changes, but will assume that
two different files are semantically independent. If they aren't, then
an automatic merge that succeeds causes additional work down the line.

Simon

[Frank Guthausen]

On Thu, 19 Dec 2024 18:03:06 +0900

Post by Simon Richter

Post by Frank Guthausen
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate
the distribution part from local overrides.

It depends on the package.

Sure. The idea can be restricted to those
projects which already offer an project.d/
folder.

And it can be extended/modified to project.example/ folders.

From my point of view both would be a lot of help for admins.
This concept can be implemented in an indepent an parallel way
by introducing packages ``project-extra-config'', which might
be flagged as recommended or suggested. This reduces risk of
breaking things or established workflows.

[Gioele Barabucci]

Post by Frank Guthausen
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.

Hi,

this is what can be called "old style" overrides.

The modern way of doing it is the "stateless" style, most commonly
associated with systemd but used by plenty of other projects, plus
"drop-in" .d directories.

The basic documentation can be found at
<https://uapi-group.org/specifications/specs/configuration_files_specification/>.
libeconf provides an implementation of the spec and its details.

Simply speaking the stateless style works like this:

* Distro/upstream configuration in /usr/lib/$proj/foo.conf (read-only)
* Admin can override the standard configuration via /etc/$proj/foo.conf
* Runtime overrides can be placed in /run/$proj/foo.conf
* User can override admin's and upstream's config via
$HOME/.config/$proj/foo.conf
* User's runtime overrides can be placed in $XDG_RUNTIME_DIR/$proj/foo.conf

In addition, snippets that add or override only part of the
configuration can be loaded from
{/usr/lib,/etc,/run,$HOME/.config}/$proj/foo.conf.d/extra1.conf

Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under /etc.

Regards,

--
Gioele Barabucci

[Samuel Thibault]

Post by Gioele Barabucci
* Admin can override the standard configuration via /etc/$proj/foo.conf

[...]

Post by Gioele Barabucci
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under /etc.

Having pre-filled configuration files ready for editting in /etc
(possibly containing only commented lines) is extremely useful for
admins.

Samuel

[Samuel Thibault]

Post by Samuel Thibault

Post by Gioele Barabucci
* Admin can override the standard configuration via /etc/$proj/foo.conf

[...]

Post by Gioele Barabucci
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under /etc.

Having pre-filled configuration files ready for editting in /etc
(possibly containing only commented lines) is extremely useful for
admins.

$ cp /usr/lib/$proj/foo.conf /etc/$proj/

Which is not trivial, really.

Samuel

[Samuel Thibault]

Post by Samuel Thibault

Post by Samuel Thibault

Post by Gioele Barabucci
* Admin can override the standard configuration via /etc/$proj/foo.conf

[...]

Post by Gioele Barabucci
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under /etc.

Having pre-filled configuration files ready for editting in /etc
(possibly containing only commented lines) is extremely useful for
admins.

$ cp /usr/lib/$proj/foo.conf /etc/$proj/

Which is not trivial, really.

Put another way: would it really be /usr/lib/$proj, or rather (since
it's arch-independent) /usr/share/$proj, or rather (since that's
documentation) /usr/share/do/$proj. How an admin would know? That's just
hiding things, compared to the decades of habits.

Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it
more difficult for the admin to configure their server?

Samuel

[rhys]

Post by Samuel Thibault

Post by Samuel Thibault

$ cp /usr/lib/$proj/foo.conf /etc/$proj/

Which is not trivial, really.

Well, it IS, but in the same way that "rm -rf /" is trivial. It's easy to do, but some non-trivial thought should occur before doing it.

Post by Samuel Thibault
Put another way: would it really be /usr/lib/$proj, or rather (since
it's arch-independent) /usr/share/$proj, or rather (since that's
documentation) /usr/share/do/$proj. How an admin would know? That's just
hiding things, compared to the decades of habits.
Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it
more difficult for the admin to configure their server?

This is how Splunk does it.

All project files are in $SPLUNK_HOME (hereafter $SH for brevity).

$SH/etc/system/default/thing.conf # defaults. strongly recommended not to edit.

$SH/etc/system/local/thing.conf # read next. admin overrides for defaults. does not have to exist.

$SH/etc/apps/$module/default/thing.conf # module-level "default overrides". system-level changes (if any) required for $module. do not edit

$SH/etc/apps/$module/local/thing.conf # module-level admin overrides for all of the above.


The part that's relevant to this conversation is that *everything* is under $SH/etc/ (and always *.conf). It makes it feasible to do things like:

find $SH/etc -type f -name thing.conf -exec grep -H 'setting' + \;

Good luck doing that with config files in 5+ places all over the filesystem.

--J

[Ansgar 🙀]

Hi,

Post by Samuel Thibault
Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it
more difficult for the admin to configure their server?

Examples belong to /usr/share/doc though?

And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

That was so annoying that Debian started having configuration files for
configuring other configuration files, e.g., /etc/default/* to
configure /etc/init.d/*.

(Yes, I know that non-default configuration for dpkg can make it more
helpful.)

Removing packages also means that random stuff gets left over in /etc
which can break other software (and does!).

(Yes, I know that users are expected to purge packages and not only
remove them to prevent that, but many users do not.)

Ansgar

[Samuel Thibault]

Post by Ansgar 🙀

Post by Samuel Thibault
Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it
more difficult for the admin to configure their server?

Examples belong to /usr/share/doc though?

Which is where I would look as second place indeed, but not
/usr/lib/$package (at best /usr/share/$package)

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

Post by Ansgar 🙀
That was so annoying that Debian started having configuration files for
configuring other configuration files, e.g., /etc/default/* to
configure /etc/init.d/*.

Or can be put in .d/ directories. But then if e.g. an option disappears,
things just break without getting any warning ahead.

Samuel

[Andrey Rakhmatullin]

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

In my (narrow) experience it's often the version number at the top and
typo and whitespace fixes.

[Andreas Metzler]

Post by Andrey Rakhmatullin

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

In my (narrow) experience it's often the version number at the top and
typo and whitespace fixes.

Hello,

Please submit bug reports against packages keeping (and updating) the
version number in a dpkg conffile and triggerring unnecessary conffile
prompts.

cu Andreas

[Marc Haber]

Post by Andreas Metzler

Post by Andrey Rakhmatullin

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

In my (narrow) experience it's often the version number at the top and
typo and whitespace fixes.

Hello,
Please submit bug reports against packages keeping (and updating) the
version number in a dpkg conffile and triggerring unnecessary conffile
prompts.

Maybe our conffile handling should be modified to automatically accept
comment-only changes to dpkg-conffiles.

Greetings
Marc

[Ángel]

Post by Marc Haber
Maybe our conffile handling should be modified to automatically
accept comment-only changes to dpkg-conffiles.
Greetings
Marc

That would require to tag what is considered a comment for each
conffile.

While most config files seem to use a # marker, other use ; (e.g.
php.ini), // or /* (firefox-esr) or even " (vimrc).

Some conffiles support multiple types of comments, while others none at
all. In some cases comments may be added at the end of lines, others
require that the comment starts the line, albeit whitespace is
*sometimes* allowed before.
In some cases conf files support a full shell syntax (you could comment
with if false; then ... fi), others only accept a tiny subset. In some
cases you can provide a multiline literal containing a comment-marker
(and there could be reasons for that, such as setting a banner with #
lines).

courier uses # comments, but lines beginning with ## are special, it
uses them so that their conffiles can be automatically upgraded (it is
clever solution to the configuration-options-change-between-versions
problem, but again, specific to this package).


I do think it would be good that it was able to do some comment-merging
(even if it is just telling you "the conffile changes are irrelevant"),
but it would require to at least define some classes of etc files on
which that would be supported (a compillation that would be useful for
other users as well, such as editors).


Regards

[Josh Triplett]

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause
problems, and vice versa.

In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the
configuration file. You add a file that has the single configuration
directive you want to change. If the upsteam configuration changes, you
automatically get the new defaults for all the other options.

I've found that often, the diffs of a complete "sample" configuration
file with commented-out defaults don't have changes to the defaults,
they tend to have new options. That makes the diff much less useful, and
much less likely to lead me to make any changes to my own configuration.

However, I think there *is* a best-of-both-worlds option here.

Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is
commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example
corresponds to in /etc.

Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.

Users who *don't* want that behavior can remove that package, and users
who *do* want that behavior could install it.

That seems like an improvement over the current situation, in which
there's a mix of packages that ship commented-defaults (causing problems
for the people who want an empty /etc) and packages that don't (causing
problems for the people who expect a sample file in /etc). It'd be a
step along the road towards having a uniform policy for handling
configuration files.

[Samuel Thibault]

Post by Josh Triplett

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause
problems, and vice versa.
In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the
configuration file.

Yes, that's why having both the ready-to-be-modified model *and* a .d/
directory fits both cases.

Post by Josh Triplett
Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed.

But isn't it what we already have? If I don't modify the example in /etc
and only add files to .d/, I'm getting upgrades without questions.
And if I modify the example in /etc, I'm getting the question. That way
I can decide per-package whether to just augment or change the
default configuration.

Post by Josh Triplett
That seems like an improvement over the current situation, in which
there's a mix of packages that ship commented-defaults (causing problems
for the people who want an empty /etc) and packages that don't (causing
problems for the people who expect a sample file in /etc).

But the assumption is the same in both case: packages should provide
an example file in a standardized place. Be it in /etc or in some
/usr/share/ doesn't change the question of having people converging to
it. And having it ready for modification in /etc is way more convenient
than having it in some /usr/share and determining where it's supposed to
be put in /etc.

Samuel

[Henrik Ahlgren]

Post by Samuel Thibault
But isn't it what we already have? If I don't modify the example in /etc
and only add files to .d/, I'm getting upgrades without questions.
And if I modify the example in /etc, I'm getting the question. That way
I can decide per-package whether to just augment or change the
default configuration.

For many packages that works well, but the devil is in the details. For
example, the most common configuration change for chrony is to use a
set of custom NTP servers, by dropping a configuration snippet under
/etc/chrony/sources.d. But the example config /etc/chrony/chrony.conf
always adds the default pool "2.debian.pool.ntp.org" unless you modify
the configuration file and comment it out, since the "pool"
configuration directive can be used multiple times. I guess this
example does not strictly follow this pattern, since the pool setting
is the only non-default setting not commented in the file.

[Samuel Thibault]

Post by Henrik Ahlgren

Post by Samuel Thibault
But isn't it what we already have? If I don't modify the example in /etc
and only add files to .d/, I'm getting upgrades without questions.
And if I modify the example in /etc, I'm getting the question. That way
I can decide per-package whether to just augment or change the
default configuration.

For many packages that works well, but the devil is in the details.

It will be with any scheme that gets devised. So the simpler scheme will
be better.

Post by Henrik Ahlgren
For example, the most common configuration change for chrony is to use
a set of custom NTP servers, by dropping a configuration snippet under
/etc/chrony/sources.d. But the example config /etc/chrony/chrony.conf
always adds the default pool "2.debian.pool.ntp.org" unless you
modify the configuration file and comment it out, since the "pool"
configuration directive can be used multiple times.

And that will get troubles with other schemes too.

One thing that could be useful is to be able to tell dpkg "never ask me
again for replacing this config file with the shipped one", and you will
get what is being proposed. Per-package.

Samuel

[Josh Triplett]

Post by Samuel Thibault

Post by Josh Triplett

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause
problems, and vice versa.
In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the
configuration file.

Yes, that's why having both the ready-to-be-modified model *and* a .d/
directory fits both cases.

I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.

Post by Samuel Thibault

Post by Josh Triplett
Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed.

But isn't it what we already have? If I don't modify the example in /etc

No, the model I was describing would have *no* file in /etc if you
remove `etc-commented-defaults`. The point here is to support the users
who want an empty /etc and the users who want files full of
commented-out defaults.

Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".

- Josh Triplett

[Samuel Thibault]

Post by Josh Triplett

Post by Samuel Thibault

Post by Josh Triplett

Post by Samuel Thibault

Post by Ansgar 🙀
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.

Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.

There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause
problems, and vice versa.
In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the
configuration file.

Yes, that's why having both the ready-to-be-modified model *and* a .d/
directory fits both cases.

I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.

What I completely fail to understand is why people would want to not see
any file in /etc. What harm does it *actually* cause?

Post by Josh Triplett
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".

Yes, agreeing on something (but also... actually getting it to actually
happen...) would be better than the current situation.

Samuel

[Ansgar 🙀]

Hi,

Post by Samuel Thibault
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?

It makes it hard to see what was actually configured: there is random
configuration bits, possibly from a random older version of the
package, intermixed with local configuration.

With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.

It also avoids the problem of removed-but-not-purged packages.

Ansgar

[Henrik Ahlgren]

Post by Ansgar 🙀
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.

It would obviously be ideal for stateless systems as well: 
http://0pointer.de/blog/projects/stateless.html

Which is radically different from what Debian (a traditional stateful
system) is today, but keeping /etc clean and tidy would still have some
benefits.

[Samuel Thibault]

Post by Henrik Ahlgren

Post by Ansgar 🙀
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.

It would obviously be ideal for stateless systems as well: 
http://0pointer.de/blog/projects/stateless.html

But being "ideal" doesn't mean it should harm other workflows. If there
is an easy-enough way to check if /etc is unmodified (that's the whole
point of ucf), why not just use it rather than change everything?

Again, it's not the *presence* of files in /etc that is the actual
problem that is being addressed. While it's their presence that helps
people who use stateful configuration.

Samuel

[Samuel Thibault]

Post by Ansgar 🙀

Post by Samuel Thibault
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?

It makes it hard to see what was actually configured: there is random
configuration bits, possibly from a random older version of the
package, intermixed with local configuration.
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.

ucf should be able to provide this?

Put another way: it's not the presence of files in /etc that poses
problem. It's not having the shipped version at hand for comparing it.
Let's fix that rather than dropping something which is useful to admins.

Post by Ansgar 🙀
It also avoids the problem of removed-but-not-purged packages.

With files copied into /etc, you will still have configuration files
lying around, and *not tracked*.

Samuel

[Ansgar 🙀]

Hi,

Post by Samuel Thibault

Post by Ansgar 🙀

Post by Samuel Thibault
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?

It makes it hard to see what was actually configured: there is random
configuration bits, possibly from a random older version of the
package, intermixed with local configuration.
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.

ucf should be able to provide this?

No, first you would need something on top of ucf. Then you would need
to make sure admins don't keep parts from random older versions which
cause noise.

And then you would need all packages to switch to ucf. Which AFAIU
requires maintainer scripts which is something people would like to
avoid as well. (To be fair: alternatives also require packaging
changes.)

Post by Samuel Thibault
Put another way: it's not the presence of files in /etc that poses
problem. It's not having the shipped version at hand for comparing it.
Let's fix that rather than dropping something which is useful to admins.

Post by Ansgar 🙀
It also avoids the problem of removed-but-not-purged packages.

With files copied into /etc, you will still have configuration files
lying around, and *not tracked*.

That problem doesn't exist if you don't copy unneeded files to /etc.

Copying files to /etc and then writing logic to filter those out of
some comparisons seems more complicated than just not copying needed
stuff. It also means I don't have to use a special program to see what
changed.

Ansgar

[Samuel Thibault]

Post by Ansgar 🙀

Post by Samuel Thibault

Post by Ansgar 🙀

Post by Samuel Thibault
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?

It makes it hard to see what was actually configured: there is random
configuration bits, possibly from a random older version of the
package, intermixed with local configuration.
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.

ucf should be able to provide this?

No, first you would need something on top of ucf.

? Can't ucf be added an option to do that?

Post by Ansgar 🙀
Then you would need to make sure admins don't keep parts from random
older versions which cause noise.

But that's only for admins to see that from ucf's new option output and
act accordingly.

Post by Ansgar 🙀
And then you would need all packages to switch to ucf. Which AFAIU
requires maintainer scripts which is something people would like to
avoid as well. (To be fair: alternatives also require packaging
changes.)

That's one of my points: this thread is already considering to ask
everybody to be doing something about it...

Post by Ansgar 🙀

Post by Samuel Thibault
Put another way: it's not the presence of files in /etc that poses
problem. It's not having the shipped version at hand for comparing it.
Let's fix that rather than dropping something which is useful to admins.

Post by Ansgar 🙀
It also avoids the problem of removed-but-not-purged packages.

With files copied into /etc, you will still have configuration files
lying around, and *not tracked*.

That problem doesn't exist if you don't copy unneeded files to /etc.

When removing a package, it should be completely fine to remove the
configuration files when it is noticed that they have not been modified.

Post by Ansgar 🙀
Copying files to /etc and then writing logic to filter those out of
some comparisons seems more complicated than just not copying needed
stuff. It also means I don't have to use a special program to see what
changed.

It seems way more often to me that I want to easily inspect/modify/amend
the configuration in /etc (without having to look whatever other place
to find out about the default configuration) than checking what changes
I have made to /etc which I may not want any more. And thus having a
special program for the latter looks completely fine to me. That's what
people do with etckeeper and such already.

Samuel

[Russ Allbery]

Post by Samuel Thibault
It seems way more often to me that I want to easily inspect/modify/amend
the configuration in /etc (without having to look whatever other place
to find out about the default configuration) than checking what changes
I have made to /etc which I may not want any more. And thus having a
special program for the latter looks completely fine to me. That's what
people do with etckeeper and such already.

And this is the root of the problem: you want one thing for understandable
reasons, and other people, like myself, would prefer the opposite behavior
of having /etc empty by default for different understandable reasons. We
both understand the other's point of view and simply disagree about the
merits of the features of the two methods.

Neither side of this preference is going to convince the other any more
than I am going to convince everyone to use Emacs, and yet every time we
have this discussion it turns into an extended effort to convince people
with the opposite preference.

Maybe it would be more productive to take the preference disagreement as
given and then try to figure out how to proceed given that we're never
going to all agree on the best way of handling configuration files? Is
there some way that we can try to accomodate both groups?

[Josh Triplett]

Post by Russ Allbery
And this is the root of the problem: you want one thing for understandable
reasons, and other people, like myself, would prefer the opposite behavior
of having /etc empty by default for different understandable reasons. We
both understand the other's point of view and simply disagree about the
merits of the features of the two methods.
Neither side of this preference is going to convince the other any more
than I am going to convince everyone to use Emacs, and yet every time we
have this discussion it turns into an extended effort to convince people
with the opposite preference.
Maybe it would be more productive to take the preference disagreement as
given and then try to figure out how to proceed given that we're never
going to all agree on the best way of handling configuration files? Is
there some way that we can try to accomodate both groups?

Elsewhere in the thread, I suggested a way to do exactly that:

https://lists.debian.org/msgid-search/Z2TfFJX8x-***@localhost
(https://lists.debian.org/debian-devel/2024/12/msg00431.html)

We could have a package that, when installed, ensures that packages have
default/commented/etc configuration files in etc, and when *not*
installed, ensures that packages don't install files that match their
defaults.

(That message outlines one possible implementation strategy, but many
different approaches could work. The key detail is to tie it to
something the sysadmin can control.)

This would make folks who want a template-populated /etc happier because
packages currently following the empty-/etc model would better respect
their preferences. And it would make folks who want an empty /etc
happier because packages currently following the template-populated-/etc
model would better respect their preferences. This would also give us a
standardized location for template /etc files, which would help folks
using either model.

I'm *not* suggesting this would be a rapid change, but it could help us
gradually work towards more uniform behavior, without people having to
give up the advantages of the model they prefer.

[Ángel]

Post by Russ Allbery
Maybe it would be more productive to take the preference disagreement as
given and then try to figure out how to proceed given that we're never
going to all agree on the best way of handling configuration files? Is
there some way that we can try to accomodate both groups?

Create a diversion from /etc to /usr/share/etc-conffiles-as-packaged

Mkdir your almost-empty etc folder on /root/etc-changes

Use a unionfs or union mount to combine /usr/share/etc-templates-as-packaged + /root/etc-changes mounted on /etc


As the cherry on top of the cake, there could be a package that did
this automatically.


The trickiest part is probably that, for early daemons to correctly use
that /etc, you may need to do that early in the boot process, in the
initrd, which is less comfortable to code. Alternatively, perhaps a
stub config on /etc would be enough for bootstrapping this (systemd
might interfere with this, though).



(*) I'm not sure the dpkg-divert mechanism would be able to handle a
diversion of /etc, but adding such support if missing would be simple
and *consistent* with the rest of the system.

[Roger Lynn]

Post by Ansgar 🙀

Post by Samuel Thibault

Post by Ansgar 🙀
It also avoids the problem of removed-but-not-purged packages.

With files copied into /etc, you will still have configuration files
lying around, and *not tracked*.

That problem doesn't exist if you don't copy unneeded files to /etc.

What happens to customised configuration files placed into an empty /etc
when the relevant package is removed or purged?

Roger

[Marc Haber]

On Fri, 20 Dec 2024 11:50:57 +0100, Samuel Thibault

Post by Samuel Thibault

Post by Josh Triplett
I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.

What I completely fail to understand is why people would want to not see
any file in /etc. What harm does it *actually* cause?

Empty /etc is another idea of the people who sell a distribution that
has config file handling that is WAY inferior to what we have since 20
years. And ours is bad in some regards already.

Please don't adopt everything that Red Hat has come up with when we
have been better than that for ages.

Greetings
Marc

[Frank Guthausen]

On Fri, 20 Dec 2024 02:05:30 -0800

Post by Josh Triplett
I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.

This sounds to be a reasonable philosophy. I support this idea.

Post by Josh Triplett
No, the model I was describing would have *no* file in /etc if you
remove `etc-commented-defaults`. The point here is to support the
users who want an empty /etc and the users who want files full of
commented-out defaults.

This model approach seems to be an universal solution. Shifting the
decision to users'/admins' choice and style would be a huge improvement.

[rhys]

Post by Josh Triplett
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".

As a long-time sysadmin - and following on my previous message - I think this is a waste of time.

Speaking as a sysadmin, I MUST ACCEPT the fact that I don't write this code. This is not my code. I can't always have my way. If the developer for a package decides that a different way is best for their package, so be it.

As the old saying goes:

"Lord, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and the wisdom to know the difference."

There's a reason the "serenity" line is first. Most of the time, it is not worth the effort to try to change something determined by others for their own reasons.

There are *thousands* of software packages out there.

It is not my business as a sysadmin to tell them all how to arrange their config files, excepting cases where their choices cause real problems. (Configs that are mode 777 is a real problem. Configs that live in /etc are not.)

I don't think it is necessary for Debian package maintainers to spend this much effort to cater to personal preferences.

I don't think it is necessary for Debian package maintainers to SQUASH personal preferences, either.

Both cases are extra work toward unreasonable goals.

There's far more work to be done that matters far more than the placement of files in /etc.

--J

[Josh Triplett]

Post by rhys

Post by Josh Triplett
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".

Speaking as a sysadmin, I MUST ACCEPT the fact that I don't write this code. This is not my code. I can't always have my way. If the developer for a package decides that a different way is best for their package, so be it.

Debian is not a distribution that says "whatever upstream does is always
right". We have Debian Policy for a reason, and part of the point of a
distribution is to ensure packages meet that policy, providing uniform
behavior for sysadmins. Policies don't change overnight, but over time
we can steer in a general direction.

[Theodore Ts'o]

Post by Josh Triplett

Post by rhys

Post by Josh Triplett
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".

Speaking as a sysadmin, I MUST ACCEPT the fact that I don't write this code. This is not my code. I can't always have my way. If the developer for a package decides that a different way is best for their package, so be it.

Debian is not a distribution that says "whatever upstream does is always
right". We have Debian Policy for a reason, and part of the point of a
distribution is to ensure packages meet that policy, providing uniform
behavior for sysadmins. Policies don't change overnight, but over time
we can steer in a general direction.

Debian is also a distribution which is worked on by volunteers, as
opposed to some distribution which employs wage slaves who have to do
whatever a product manager dictates.

So a question we have to ask ourselves is "is this worth our volunteer
bandwidth"? And is it a good thing to have a Debian Policy that will
be wildly ignored, because no one has a time to make non-upstream
compliant changes (some of which might require making semantic changes
in how config files work --- example: ntp server specification has
mentioned upthread --- assuming that making a semantic change to a
config file not updated by upstream is a good thing, which I as an
upstream maintainer have a rather strong and violent reaction to with
respect to uppity distributions)?

Is having a single, unitary config file semantics a nice thing? Sure;
my having enough cash that I can work on whatever I want, and fund
teams to do whatever I want, as opposed to what my employer considers
important would also be "a nice thing". But we can't always have
everything that we want. Most of us are privileged enough to have
anything we want; but most of us also don't have enough resources to
have *everything* that we want.

- Ted

[Josh Triplett]

Post by Theodore Ts'o

Post by Josh Triplett
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".

no one has a time to make non-upstream
compliant changes (some of which might require making semantic changes
in how config files work

I am not suggesting rewriting the handling of configuration files in
software, or modifying the software in any way. That's an independent
change and one that requires convincing upstream.

I am suggesting that, for software which *already* provides an
example/template configuration file (whether in /etc or in
/usr/share/doc), *and* which does something vaguely sensible without
having that file installed, we standardize the paths in which Debian
packages install those example/template configuration files, and provide
an easy way for sysdamins to decide whether those files get installed to
/etc or just stay in /usr/share/doc. That would *only* be a change to
Debian packaging, standardizing the locations in which files get
installed for consistency.

[Richard Lewis]

Post by Josh Triplett
Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is
commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example
corresponds to in /etc.
Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.
Users who *don't* want that behavior can remove that package, and users
who *do* want that behavior could install it.

Isnt this basically implementing the systemd approach, where a package
would ship default configuration in /usr/lib/package (with all defaults,
which dont need to be commented out) and the user can override by
putting files in /etc/package -- either by copy-and-edit or just adding
individual changes. (I think systemd-sysctl does this, also suppporting
/run/ for temporary changes?)

I think systemd can already tell you how the locations have been merged
together (eg 'systemctl cat' does this), but perhaps what is missing is
a way to see what changed on upgrade (you'd want to save the clean
version from the _previous_ version of a package to be able to do that
after the upgrade)?

[Samuel Thibault]

but perhaps what is missing is a way to see what changed on upgrade
(you'd want to save the clean version from the _previous_ version of a
package to be able to do that after the upgrade)?

You mean ucf?

Samuel

[rhys]

Post by Richard Lewis

Post by Josh Triplett
Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is
commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example
corresponds to in /etc.
Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.
Users who *don't* want that behavior can remove that package, and users
who *do* want that behavior could install it.

Isnt this basically implementing the systemd approach, where a package
would ship default configuration in /usr/lib/package (with all defaults,
which dont need to be commented out) and the user can override by
putting files in /etc/package -- either by copy-and-edit or just adding
individual changes. (I think systemd-sysctl does this, also suppporting
/run/ for temporary changes?)
I think systemd can already tell you how the locations have been merged
together (eg 'systemctl cat' does this), but perhaps what is missing is
a way to see what changed on upgrade (you'd want to save the clean
version from the _previous_ version of a package to be able to do that
after the upgrade)?

This is why there won't ever be "one policy to rule them all" for configuration files. The issue isn't an inconsistency in the way the packages are built. Sufficient work by packaging teams, over time, could simply set a policy and work toward that.

The problem is that different apps interpret their configs in different ways when a directive is encountered multiple times:

1. second instance overrides
2. first instance overrides
3. instances accumulate
4. error condition

That's just off the cuff. There are probably more cases involving context-specific instances and so on. But this variation is necessary as each case will follow the needs of the package.

If I were in charge of the world (which I am not), I would merge the "Splunk approach" with some of the comments I've seen here as follows:

1) "package defaults" and/or "package templates" in /usr/share. These would be meant as references and/or as a means to restore a package back to defaults if/when the active configs are such a mess that the admin decides to start over.
2) "system global" in /etc/package/package.conf. This could be the "everything commented" style, like sshd, or it could be the actual defaults like Splunk, depending on whether the package does "overrides" or not. Splunk does overrides. Sshd does not.
3) "site add-ins" in /etc/package/conf.d (or similar). We're all familiar with this. I don't need to explain.

This way, all configs for $package are in /etc/package. I still think it's reasonable to have package.conf and package.d/ in /etc, though it's kind of annoying in a few cases. Either way, the active configs are simple to find, but are still technically separated from the documentation/failsafe defaults in /usr/share which acts like a sort of "vault" that isn't part of the active config (and is thus less likely to be modified by inexperienced admins who ignore the "DO NOT EDIT THIS FILE" warning at the tops of default global configs).

Any package that allows ~/.config/user-overrides isn't really affected by any of this. Those are all the user's problem, though nothing precludes a /usr/share/package/user-orverrides example file for whatever reason that might be useful.


What I don't think will ever be unified is the contents of that global config, wherever it lives. Some will be "defaults all shown and active." Others will be "defaults shown but commented." Still others will be "defaults shown but must be edited" (NTP). I don't think there's much of a way around that, since developers will code their packages the way they want to, and preferences about this sort of thing are too much subject to drift over time.

(Side note: It would be handy for these styles to have names, just to speed up conversation, assuming they don't already.)

Anyway, I don't see these variations as a weakness, but rather as a demonstration of the flexibilty of the system. While it's certainly good to have one or more recommended ways of doing things, there doesn't have to be One Right Way for everything. That would be both boring and restrictive.

--J

[Daniel Gröber]

Hi Josh,

Post by Josh Triplett
Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is
commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example
corresponds to in /etc.
Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.

I've had the same idea floating around my head for a while now too, thanks
for writing it down <3

While codifying the default config path (/usr/share/doc/examples/etc in
your example) in the long run would be nice and clean in many cases
individual maintainers would need to be convinced to follow that
convention, however the etc-commented-defaults package could also just
special case the locations where needed. I like that aspect of the idea.

As an example I'm familiar with iproute2 moved it's default config from
/etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
the config from there, it's not just example files so in that case upstream
patching or symlink trickery would be required to make the package
conformant to this convention.

I've tried arguing this is a blatant disregard of policy but that fell on
deaf ears so far.

I wonder how many other packages do this now that this idea of empty-/etc
is fashionable, I've no idea how we might find them though.

--Daniel

[Gioele Barabucci]

Post by Daniel Gröber
As an example I'm familiar with iproute2 moved it's default config from
/etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
the config from there, it's not just example files so in that case upstream
patching or symlink trickery would be required to make the package
conformant to this convention.
I've tried arguing this is a blatant disregard of policy but that fell on
deaf ears so far.

How is that against policy?

Is it against policy to have default config values hardcoded in a
binary? Why things change if these hardcoded values are moved to a
read-only file in /usr? (The user/admin configuration is still in /etc.)

Regards,

[Daniel Gröber]

Hi Gioele,

Post by Gioele Barabucci

Post by Daniel Gröber
As an example I'm familiar with iproute2 moved it's default config from
/etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
the config from there, it's not just example files so in that case upstream
patching or symlink trickery would be required to make the package
conformant to this convention.
I've tried arguing this is a blatant disregard of policy but that fell on
deaf ears so far.

How is that against policy?
Any configuration files created or *used* by your package must reside in
/etc, [...]

(Emphasis mine)

Post by Gioele Barabucci
All configuration files must reside in /etc.
Is it against policy to have default config values hardcoded in a binary?

No, but if there's a config file that the program actually reads it has to
be in /etc. (Ok technically policy also allows to "put the files in /etc
and create symbolic links to those files from the location that the package
requires." ;)

Post by Gioele Barabucci
Why things change if these hardcoded values are moved to a read-only file in
/usr? (The user/admin configuration is still in /etc.)

Because traditionally the expectation has been that editable files are
present in /etc. I don't think I've ever come across a package that
violated this expectation before this recent empty-/etc push but perhaps
others know of examples outside my bubble here?

--Daniel

[Russ Allbery]

Post by Daniel Gröber

Post by Gioele Barabucci
Any configuration files created or *used* by your package must reside in
/etc, [...]

(Emphasis mine)

Policy has a specific definition of configuration file, which makes your
point here somewhat ambiguous, but I can understand this misreading and
therefore think this is a bug in Policy that we should fix. It has
certainly never been the case that every file loaded by a binary that
controls operation of that binary was required to be in /etc, and I can
name numerous packages that predate and are not attempting to follow the
empty-/etc configuration model (such as zsh, autoconf, inn2, and every
package that loads *.desktop files) as obvious cases of loading
configuration information from /usr.

The intended principle here is that configuration files *that may be
edited by a system administrator* should be in /etc. Not files that are
intended to be read-only or configuration information shipped by Debian
that the local administrator should not need to edit. That's entirely
consistent with a model where the override files edited by the system
administrator are in /etc and the defaults they are overriding are
somewhere in /usr; Policy doesn't care whether they are hard-coded inside
some binary or present on disk in some loadable form.

I'll open a bug against debian-policy so that we can clarify the wording
and avoid this misreading.

[Gioele Barabucci]

Post by Samuel Thibault

Post by Gioele Barabucci
* Admin can override the standard configuration via /etc/$proj/foo.conf

[...]

Post by Gioele Barabucci
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under /etc.

Having pre-filled configuration files ready for editting in /etc
(possibly containing only commented lines) is extremely useful for
admins.

$ cp /usr/lib/$proj/foo.conf /etc/$proj/

Default conf files can contain (and often already contain) comments.

Regards,

[rhys]

Post by Gioele Barabucci
this is what can be called "old style" overrides.

Things get to be "old" because they actually work well.

Post by Gioele Barabucci
The modern way of doing it is the "stateless" style, most commonly associated with systemd but used by plenty of other projects, plus "drop-in" .d directories.
The basic documentation can be found at <https://uapi-group.org/specifications/specs/configuration_files_specification/>. libeconf provides an implementation of the spec and its details.
* Distro/upstream configuration in /usr/lib/$proj/foo.conf (read-only)
* Admin can override the standard configuration via /etc/$proj/foo.conf
* Runtime overrides can be placed in /run/$proj/foo.conf
* User can override admin's and upstream's config via $HOME/.config/$proj/foo.conf
* User's runtime overrides can be placed in $XDG_RUNTIME_DIR/$proj/foo.conf
In addition, snippets that add or override only part of the configuration can be loaded from {/usr/lib,/etc,/run,$HOME/.config}/$proj/foo.conf.d/extra1.conf

What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?

I'm sorry but this is just SILLY. Spewing files all over the filesystem like this is exactly why things like /opt and /usr/local got created: to GROUP package-related files together.

<sigh> The pendulum swings, I suppose.

--J

[Henrik Ahlgren]

Post by rhys
What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?

The group is called "The Linux Userspace API (UAPI) Group", and according
to their home page, it consists of from people from Ubuntu Core, Debian,
GNOME OS, Fedora CoreOS, Endless OS, Arch Linux, SUSE, Flatcar, systemd,
image-builder/osbuild, mkosi, tpm2-software, System Transparency,
buildstream, BTRFS, bootc, composefs, (rpm-)ostree, Microsoft, Amazon, and
Meta.

You are free to disagree with this design, but please don't call the people
behind it idiots. I am pretty sure there are plenty of very competent
people who have given this a lot of thought.

[rhys]

Post by Henrik Ahlgren

Post by rhys
What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?

The group is called "The Linux Userspace API (UAPI) Group", and according
to their home page, it consists of from people from Ubuntu Core, Debian,
GNOME OS, Fedora CoreOS, Endless OS, Arch Linux, SUSE, Flatcar, systemd,
image-builder/osbuild, mkosi, tpm2-software, System Transparency,
buildstream, BTRFS, bootc, composefs, (rpm-)ostree, Microsoft, Amazon, and
Meta.
You are free to disagree with this design, but please don't call the people
behind it idiots. I am pretty sure there are plenty of very competent
people who have given this a lot of thought.

I do tend to reserve my contempt to the few cases where it is appropriate.

But seriously, after 30+ years of working with various systems from NeXTStep to Windows to VAX, this all smacks of people who haven't learned anything from history and/or haven't spent enough time managing more than a few systems in one or two contexts.

"A lot of thought" in an echo chamber still has the same result, only worse. It reinforces itself without any real basis.

So now they're suggesting going down a road we've been down before. More than once.

Therefore, "idiots."

Sorry, but repeating history when nothing about the underlying situation has changed will never be smart.

--J

[Tobias Frost]

Post by rhys

Post by Henrik Ahlgren

Post by rhys
What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?

The group is called "The Linux Userspace API (UAPI) Group", and according
to their home page, it consists of from people from Ubuntu Core, Debian,
GNOME OS, Fedora CoreOS, Endless OS, Arch Linux, SUSE, Flatcar, systemd,
image-builder/osbuild, mkosi, tpm2-software, System Transparency,
buildstream, BTRFS, bootc, composefs, (rpm-)ostree, Microsoft, Amazon, and
Meta.
You are free to disagree with this design, but please don't call the people
behind it idiots. I am pretty sure there are plenty of very competent
people who have given this a lot of thought.

I do tend to reserve my contempt to the few cases where it is appropriate.
But seriously, after 30+ years of working with various systems from NeXTStep to Windows to VAX, this all smacks of people who haven't learned anything from history and/or haven't spent enough time managing more than a few systems in one or two contexts.
"A lot of thought" in an echo chamber still has the same result, only worse. It reinforces itself without any real basis.
So now they're suggesting going down a road we've been down before. More than once.
Therefore, "idiots."
Sorry, but repeating history when nothing about the underlying situation has changed will never be smart.
--J

Rhys,

this mailing list is covered by the Debian CoC. Calling anyone names
is inappropiate, so either cease doing so on Debian resources or stop
posting at all.

--
tobi