Bruno Haible via Gnulib discussion list <[email protected]> writes: > The approach looks reasonable to me. Of course, I'll also value the opinion > of the other Gnulib and coreutils contributors.
FWIW, my opinion is that avoiding hard link-time dependencies on anything systemd-related for things like readutmp would be good: these binaries were often usable without anything systemd-related before, like in a minimal container environments, and pulling in systemd only to get readutmp functionality seems excessive to me. It seems like a better trade-off to just have readutmp return garbage in this scenario. Maybe this could be up to the application? We could have a gnulib module 'readutmp' that works like today, but add a 'readutmp-optional' were having the API/ABI is what's important, and having it return proper data is secondary. Probably readutmp() and readutmp_optional() APIs are needed, too, for multi-application projects were two different tools have different preferences. There are several tools in GNU InetUtils that uses readutmp. For example, InetUtils syslogd uses readutmp.h. Having the built binaries always depend on the systemd ecosystem prevents using them in minimal environments. It would be nice it syslogd wouldn't a link-time dependency on anything systemd-related. /Simon
signature.asc
Description: PGP signature
