* 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. 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. Thanks, Florian -- _______________________________________________ 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
