Hi, There is a long-term goal of moving packaged files out of /etc, so that only actual local configuration remains in /etc. This has some advantages: - Local configuration, i.e. the result of local administrative actions, is nicely split from static configuration that is part of package payload. 'find /etc' will show what is special to this local system, while 'find /usr' lists stuff that is part of packages and the same between systems. - We can support "factory reset" at the system level, i.e. do 'rm -rf /etc' to return everything to distro defaults. We're not there _yet_, but it works with a surprisingly large subset of packages. - We can support "factory reset" at a package level, by removing all the configuration and state of an individual package, without reinstalling it (possibly combined with some tmpfiles.d config to recreate things automatically.) - It becomes easier to build systems which are delivered as a stand-alone /usr-partition. This could be ostree-style systems, or image-based systems with the /usr-partition read-only and protected by dm-verity. We're not there _yet_, but many people are experimenting with this. When one looks in /etc, many of the files there are not "configuration". For example, /etc/services is a list of port:service mappings, and people maybe used to edit that twenty years ago, but now it's just a static file that just as well may be somewhere under /usr/lib/. The same is also true for /etc/bash_completion.d/ — people do not edit completion scripts. Most of those have been moved to /usr/share/bash-completion/completions/, but there's still a dozen or so in /etc. Another common case is "empty" configuration files, i.e. templates that show the default configuration. E.g. systemd has files that show commented-out defaults, so if the file is removed, there is no change in behaviour. Other distributions are ahead of us in supporting empty /etc. In particular, OpenSUSE has done a lot of work with libeconf, which adds support for systemd-style config in /usr/lib, /etc, and /run, and has convinced various projects to switch to libeconf and allow empty /etc. There is a specification codifying best practices in this area at: https://uapi-group.org/specifications/specs/configuration_files_specification/ systemd-255-3.fc40 that was just built for rawhide moves "empty" config files from /etc/systemd to /usr/lib/systemd. Systemd programs look in both locations, so there should be no change in behaviour. Ideally, when administrators want to make local modifications, they will use a drop-in file, instead of editing the main config file, so the location of the main config file doesn't matter. (To make this all nicer, we have systemd-analyze cat-config which will display all config files in priority order, including drop-ins, and we now added systemd-analyze cat-config --tldr which will suppress "empty" stuff (empty lines and comments).) If you are a maintainer of a package with files in /etc, please consider whether they are strictly necessary, and if possible, move stuff to /usr. If you are a maintainer of an upstream project, make sure that it supports loading files from under /usr, so that the distro can put its config files there. See https://github.com/uapi-group/specifications/issues/76 for a tracker bug with a list of usptream projects which don't support this. At some point, I think we should make this an explicit goal in Fedora. I don't think we're at the point yet where it'd be feasible to put this in Packaging Guidelines, but we can already convert individual packages. Zbyszek (on behalf of various folks working on this) -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
