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

[Eli Schwartz]

On 8/23/20 10:50 AM, Geert Hendrickx via arch-general wrote:
> Hi
> 
> A number of packages depend on inetutils merely for the `hostname` command.
> Common packages include xorg-xinit and mariadb, which makes that inetutils
> is still installed on a large number of Arch systems, although its other
> components like rcp, rsh, talk, telnet ... and their server counterparts,
> are really old, deprecated, and totally insecure.  Plus the implementation
> seems to be largely abandoned by upstream (see FS#61041).  Needless to say,
> I don't want any of these installed on my systems.

Why is it bad if you have it installed but not running?

Anyway, xorg-xinit could probably not depend on inetutils at all, since
it only uses it to check `xauth list "$(hostname -f)"` which will always
fail because you actually do not want the --fqdn there. (For some odd
reason it only does this if you're using Linux *and* a GNU
implementation like the inetutils or gettext ones, but for busybox it
omits the -f, even though busybox supports -f.) It makes no practical
difference whether the routine fails because of a programming error or
because of a missing dependency.

You could use https://www.archlinux.org/packages/community/any/sx/ which
doesn't depend on inetutils.

For xorg-xinit, Geert's proposed patch gets rid of the incorrect -fqdn
as a side effect of switching to the portable uname -n.

> Since `hostname` is still somewhat common though, there are probably more
> implicit dependencies on it, for example FS#66603.
> 
> So I would like to eliminate dependencies on inetutils just for hostname,
> in one of the following ways:
> 
> 1/ Split the inetutils package and provide hostname as a sub-package (but
>    then still need to maintain inetutils)
> 
> 2/ Package the Debian implementation, also used by Fedora and others (but
>    this includes other legacy shit like `nisdomainname` and `ypdomainname`)
>    See https://packages.qa.debian.org/h/hostname.html
> 
> 3/ Use the implementation provided by gettext (/usr/lib/gettext/hostname),
>    which is already part of base, and thus eliminates the need for explicit
>    dependencies.  Although this implementation can only *get* the hostname,
>    not *set* it, that's all the dependent packages need, and setting the
>    hostname is nowadays handled by systemd's `hostnamectl` anyway.

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`.

The gettext thing seems like deep, dark magic, and the fact that a
hostname program even exists in there is due to deep dark magic inside
/usr/bin/msginit which invokes the shell script
/usr/lib/gettext/user-email in order to grep various programs (mutt,
openoffice, Thunderbird, netscape, emacs) with complicated fallbacks
before prompting you to select an option or input your own email address
when authoring a PO translation file.

I don't think we should be relying on this level of indirection. It
could be dropped at any time.

> My preference would be 3/, for simplicity.  I already run my systems with
> /usr/bin/hostname symlinked to /usr/lib/gettext/hostname (after forcibly
> removing inetutils), and noticed no issues.
> 
> This can be done in two steps:
> i.  make the gettext package install (or symlink) /usr/bin/hostname,
>     drop it from inetutils, and introduce mutual conflicts on older
>     versions of each.
> ii. drop the dependency on inetutils from other packages (or replace it
>     with a dependency on hostname if options 1/ or 2/ are preferred).
> 
> Fans of `telnet` can continue to install inetutils manually, of course. ;-)

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".

-- 
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/975b14d2/attachment.sig>