On Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > >> 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. > > I want to replace nss_wrapper with a simple set of environment > variables. Once we have a multi-file search path, it's no longer so > simple because it's not clear if the default search path is amended or > replaced when the environment variable is set.
nss_wrapper currently fully overrides the system config. I think it'd be reasonable to keep that behaviour. But anyway: having to make that choice here is not a great argument against having multiple files, we just have to remember about the issue and implement and document one of the possibilities, whatever makes the most sense. > Loop detection on traditional file systems wouldn't be very difficult to > implement, except that we increasingly have file systems which have > dev_t/ino_t values that are not unique. But that impacts any form of > loop detection, so I'm not overly concerned. Yes, it certainly _can_ be done… The systemd-style drop-in mechanism works well and is at this point widely documented and understood. We also have cases where alternative mechanisms based on 'include' were implemented, and, at least in my opinion, they have proven to work less well. (E.g. sshd, sudo). Anyway, I think that at this point the technical arguments have been laid out, and we're down to questions of style. I _like_ the proposal with a fixed set of file paths better, but I'd be happy to take the version with include directives too, if it means we move some files out of /etc. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
