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

[Eli Schwartz]

On 8/27/20 3:37 PM, Geert Hendrickx wrote:
> On Thu, Aug 27, 2020 at 15:27:19 -0400, Eli Schwartz via arch-general wrote:
>> 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.
> 
> 
> 
> Ok, FS#61041 then ;-) (still open)
> 
> 
> Anyway, the next sentence still stands; it's just deprecated.
> 
> We made efforts deprecating ifconfig years ago[*], then why
> not rsh and friends?

Well, ifconfig is deprecated by the fact that upstream software dropped
it in favor of iproute2. I've already pointed out I agree with the
upstream patches to drop hostname in favor of uname -n.

That doesn't mean it's bad if ifconfig is installed, and in fact,
net-tools, which provides ifconfig, is still in [core], and still has
packages which depend on it, and probably has users who prefer it
instead of `ip`.

Likewise, it shouldn't be bad to have inetutils installed, merely...
deprecated. I encourage upstream projects to get with the times and use
uname -n. ;)

Thank you for doing your part to make the world a little bit less of an
inetutils-using place!

That doesn't mean Arch needs to change how hostname is packaged, though.

Inert software that merely sits on your disk should not be problematic,
no matter how old-fashioned or even buggy it is, unless:

- you actually try running it
- or services run it automatically by default, but they should not be
  enabled by default
- or unless it is setuid (rcp/rlogin/rsh are indeed, and if they are
  in fact dangerous this needs to be fixed directly as rexec was, rather
  than endangering the telnet lovers).

-- 
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/71cdc40e/attachment.sig>