On 8/27/20 3:17 PM, Geert Hendrickx wrote: > On Thu, Aug 27, 2020 at 14:34:41 -0400, Eli Schwartz via arch-general wrote: >> Why is it bad if you have it installed but not running? > > > FS#41834 as an example. Or FS#28819. There is just no good reason to keep > dragging purely historic crap like inetutils on so many Arch systems just > because a few common tools want `hostname`. That's just a bug in packaging. :p It's the same bug if you genuinely want to have telnet installed due to being a fan of telnet, and install it manually. >> Or 4) submit upstream patches to make such programs first try to read >> /proc/sys/kernel/hostname instead of shelling out, or invoke `uname -n` >> rather than `hostname`. > > > Yes, that's what I just added. ;-) However `cat /proc/sys/kernel/hostname` > is even less portable than `hostname`. `uname -n` is defined by POSIX and > thus preferred. A few upstreams already agreed on that. I do entirely agree, but xorg-xinit was special-casing Linux *anyway*, and /proc/sys/kernel/hostname should work on any system with a Linux kernel regardless of installed tools. >> The gettext thing seems like deep, dark magic, [...] I don't think we >> should be relying on this level of indirection. It could be dropped at >> any time. > > > Yes, I realized that once looking deeper into the gettext implementation, > it should not be relied on. If we really want a /usr/bin/hostname in base, > better just make it a wrapper around `uname -n`. > > >> Eventually we will have >> https://wiki.archlinux.org/index.php/User:Allan/Alternatives and then >> you could install your own preferred hostname implementation without >> conflicts. It would not be unreasonable at that time to make packages >> depend on a virtual provides for "hostname". > > > Seems overkill for trivial utilities like hostname. It's not like > switching between different JDK implementations or such. > > > Geert > > > -- Eli Schwartz Bug Wrangler and Trusted User
Attachment:
signature.asc
Description: OpenPGP digital signature
