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