[arch-general] drop dependencies on legacy inetutils for `hostname`
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. 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. 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. ;-) WDYT ? Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
On Sun, Aug 23, 2020 at 16:50:03 +0200, 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.
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.
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.
Actually even better is 4/ avoid `hostname` as well (as it's not defined by POSIX), and use portale `uname -n` instead. I've created some requests with upstream projects including mariadb[1], testssl.sh[2], xorg-xinit[3], let's see. Geert [1] https://jira.mariadb.org/browse/MDEV-23589 [2] https://github.com/drwetter/testssl.sh/pull/1707 [3] https://gitlab.freedesktop.org/xorg/app/xinit/-/issues/18 -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
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
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`.
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.
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 -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
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
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? Geert [*] https://www.archlinux.org/news/deprecation-of-net-tools/ -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
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
participants (2)
-
Eli Schwartz
-
Geert Hendrickx