On Fri, Dec 08, 2023 at 07:25:08PM +0100, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > 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. > > No, it would be the other way round. We might have a > /usr/share/glibc/services which contains :include: /etc/services > somewhere in it. Ah, OK. I understand how the format would look, but I don't understand why you'd want to implement it rather than something simpler. /etc/services is essentially a flat file that is scanned from top to bottom until a matching entry is found. In the proposed syntax, it'd need to have ':include: /etc/services' at the very top, so that the local config in /etc/services has higher priority. Consider the following alternative: each of [/etc/services, /usr/etc/services] is scanned in order, if the file exists. This is simpler to implement and allows either of the files to exist independently of the other. A stanza like ':include:' also opens the door for additional complications like different paths on different distros and include loops. It is _possible_, but the simpler scheme has the properties that we want. > > 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. > > Are you sure you mean check “for /etc/services, and if doesn't exist, > fall back to /usr/etc/services”? That suggests that in order to edit > the file, you have to make a copy, and that means that the system won't > receive any services added to the system file. “Look for the service in > /etc/services, and if it's not there, check /usr/etc/services” would > make more sense to me. But that's not so far off from :include: > processing … Yeah, I see the misunderstanding now. With config files, we generally want the behaviour that _only one_ file is used. Either /etc/foobar.conf or /usr/lib/foobar.conf, but not both. But for /etc/services, we want to combine both parts, and doing it as you describe (or as I wrote above before reading part of your mail ;) ), is better. (Of course, there's always the option of allowing both, i.e. having a main config file that is fully overriden by a file with the same name, and allowing drop-ins to extend the configuration.) 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
