[arch-general] drop dependencies on legacy inetutils for `hostname`

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200827/91cfa67b/attachment.sig>