I'm not entirely sure if you're just doing Friday trolling or if you're serious. I'll reply for real, apologies if this was meant as a joke. On Fri, Dec 08, 2023 at 12:59:22PM -0500, DJ Delorie wrote: > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes: > > There is a long-term goal of moving packaged files out of /etc, > > I will note that I'm opposed to this goal as a goal per-se. > > If you want an empty directory, "mkdir /etc2" should work for you. > > I fear this will end like the /tmp fiasco where one /tmp became many tmp > directories, and no consistent rule about which one to use. /tmp is generally backed by RAM and does not survive a reboot. /var/tmp is backed by disk and survives a reboot. The general rule is pretty clear: ISOs go to /var/tmp, quick temporary files go to /tmp. > > so that only actual local configuration remains in /etc. > > This can be achieved without "empty /etc" as a goal. For example, why > can't we use podman's overlay filesystem to mount /usr/etc under /etc so > that all the configuration appears in /etc but installed vs changed > files are kept segregatable? (FTR, not "podman's". The filesystem is a kernel thing.) If the goal was to just move everything wholesale, that'd be a possible solution. But we actually want to keep things that are local configuration and move things that are not. So the distinction between the two types of files still needs to be made. At least at the packaging level, we would need to put files in a different place. And then the software that reads the files would occasionally want to distinguish the two types of config (e.g. to present to the user whether it's the packaged default or local config, or to merge with other configuration sources with different priority). So the split would "leak" into the software anyway, and then it'd need to be prepared to handle the overlay, and possibly go into the lower layers. So now we have a much higher level of complexity (three locations, upper, lower, and combined) to achieve essentially the same functionality. (Another problem is that this scheme only works "live". If you want to look *into* an image from the outside, the overlay wouldn't be assembled, so the tools need to know how to handle the config split manually.) > > For example, /etc/services is a list of port:service mappings, and people > > maybe used to edit that twenty years ago, > > I still edit this one. Great for you. So you can be the one person who uses the override mechanism for this file. > > The same is also true for /etc/bash_completion.d/ > > I delete this package completely, so I don't care where its config goes. YMMV. > > Another common case is "empty" configuration files, i.e. templates > > that show the default configuration. > > I find these VERY helpful when trying to fix configuration issues on my > machines. Right. I'm not saying that those should go away. Quite the opposite. My first email had a long paragraph about how to display those files for systemd in a nice way (with priority sorting, highlighting, and other niceties.) Please note that the proposed scheme makes those files *more* useful: the user can have a local copy with changes. Before, when the package was updated, we wouldn't override the user's copy, so at best there'd be a .rpmnew file. Now, the package copy is in a different location and can be updated freely. > > Other distributions are ahead of us in supporting empty /etc. > > "Be like everyone else" is not one of our goals. > > > 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. > > Unless such file could be changed by a user, in which case it belongs in > /etc. The option of modifying a package file in place doesn't work great. The package updates the file and then the user is left with a copy that stops being updated. The approach of only overriding the parts that should be overriden is better. > > At some point, I think we should make this an explicit goal in Fedora. > > Please don't. You seem to like the current scheme. But it was designed in the times where people did much more manual tweaking of their systems. We now care a lot about clean and automatic upgrades. Having to resolve three-way differences between a bunch of config files conflicts with that. Zbyszek -- _______________________________________________ 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
