On 12/11/23 12:31, Neal Gompa wrote: > On Mon, Dec 11, 2023 at 11:36 AM David Cantrell <dcantrell@xxxxxxxxxx> wrote: >> >> On 12/8/23 10:25, Stephen Gallagher wrote: >>> On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek >>> <zbyszek@xxxxxxxxx> wrote: >>>> >>>> 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. >>>> >>> >>> One thing that is becoming much more common is for us to ship such >>> static files in /usr/lib and include a default symlink in /etc for >>> those packages whose presence there is effectively API (for example >>> /etc/os-release is a symlink to /usr/lib/os-release, similarly >>> /etc/resolv.conf). I think this is a very good approach and one that >>> we should probably look at formalizing in the packaging guidelines. >> >> I'd rather see defaults under somewhere in /usr/share rather than /usr/lib. >> > > I agree with this. I really would rather it be in /usr/share. > >>> That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/* >>> and /etc/fstab which are both API *and* sometimes see manual updates. >>> These are some of the cases that are going to make getting to an empty >>> /etc very hard to finish off. There's a lot of low-hanging fruit we >>> can take care of in the meantime, but getting the last 1% of packages >>> done is going to take a lot of inter-distro conversations. >> >> We could just have an /etc tree like we see now but in /usr/share/etc >> (or /usr/etc, but then I get IRIX nightmares) and your local overrides >> exist in /etc. Things like fstab will probably just have to always be >> host-dependent so they will always exist in /etc. >> > > We're currently not allowed to use /usr/etc (not that I like that path > anyway) because it breaks RPM-OSTree. My understanding is that this > directory is reserved by RPM-OSTree for storing pristine copies of > /etc content for each OSTree commit. Right, my mention of /usr/etc in parens was merely to mention some directory I remember from IRIX. The documentation noted that /usr/etc was for "Critical system configuration files and maintenance commands" which was not to be confused with /etc on IRIX which was for "Critical system configuration files and maintenance commands". :) I think /usr/share/etc would be appropriate for Fedora. >> For this to be really clean and nice, everything that drops a file in >> /etc needs to handle the "read in the default; then read in the optional >> local overrides" model. I know a lot of stuff already does this, but >> some things don't. It would be a nice goal to aim for and maybe we can >> submit patches to upstream projects where the functionality is missing. >> > > Indeed. > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > _______________________________________________ > 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 -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT -- _______________________________________________ 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
