On Fri, Dec 08, 2023 at 05:23:08PM +0100, Florian Weimer wrote: > * Stephen Gallagher: > > > 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 add some sort of :include: processing to glibc, but that's > going to impact much more than just glibc in the end (Go has its own > parser for /etc/passwd, I believe others have their own for > /etc/nsswitch.conf). IIUC, you mean that e.g. /etc/services would still exist, but would contain ":include:/usr/etc/services". That's not a great answer, because you still need /etc/services to exist. It's also a rather complex solution, because special parsing is needed… It's both easier and more powerful to say "check for /etc/services, and if doesn't exist, fall back to /usr/etc/services". It's: - simple to implement and understand, - backwards compatible in the sense that a local system that has the file modified will work without changes, - and as discussed in another part of the thread, we can add optionally add tmpfiles.d config to symlink /etc/services → /usr/etc/services on boot if there are other consumers that don't yet support the new location. Yet another approach is to allow *multiple* files, like with sysusers.d or tmpfiles.d. For '/etc/services', this would make a lot of sense, because users generally would want to override or add a few lines, and keep the rest of the config unchanged. The case of glibc is very special. It'd be great to move its files out of /etc too, but each file might need some custom mechanism and discussion about the best approach. 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
