Bug #21095: Prefer `uname -n` over `hostname` in tests.

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED, 3.4: DONE

[ioquatix (Samuel Williams)]

It turns out that hostname, while a defacto standard, is not actually a standard in any official sense. On Linux, it's distributed as part of the inettools package, and while generally available on other platforms (BSD, Windows, MacOS), it isn't actually part of any standard.

The uname(1) system call and uname(2) command ARE standardised by POSIX and the Open Group, and are included in most base systems without the need to install extra packages (e.g. inettools on Linux).

As such, I was requested by the Arch Linux Ruby maintainer, to prefer using uname -n as they would like to drop the dependency on inettools which has various issues; see https://gitlab.archlinux.org/archlinux/packaging/packages/inetutils/-/issues/2#note_211062 for more context and background.

I've been asked if this can be back ported to 3.3 and 3.4 and while it's not strictly a bug, it will reduce friction in the distribution channels, so I'd like to propose that we backport to 3.4 and if possible 3.3 too.

[ioquatix (Samuel Williams)]

Fixed in https://github.com/ruby/ruby/commit/46b544c54955348ef1ea9692b837b061f59f91cd and https://github.com/ruby/ruby/commit/d3abee739f4feb91bb9aaae33877d70c8c576db0.

[Eregon (Benoit Daloze)]

• Description updated (diff)

[Eregon (Benoit Daloze)]

My 2 cents on this is it would be far less effort to add a test dependency on inettools in Arch than changing the specs and backporting.
IMO this is no bug, the issue only arises because Arch is trying to remove some common binary, such breakage is to be expected and seems easily fixable there.

[ioquatix (Samuel Williams)]

• Description updated (diff)

[ioquatix (Samuel Williams)]

Ruby should prefer (POSIX) standardised tools and interfaces where possible. This change costs us nothing and reduces downstream friction. it's win-win for everyone, including other distributions which have to maintain their own package for hostname - did you read the background context and linked issues?

[Eregon (Benoit Daloze)]

This change costs us nothing

It costs maintenance time, and IMO already far too much of it for such a small unimportant thing.
Whatever we do here will not impact other distros keeping hostname or not, I'm pretty sure they don't keep it just for this usage.

[Eregon (Benoit Daloze)]

did you read the background context and linked issues?

I have read the linked comment, there is not much else there. I don't have time to read other issues like https://gitlab.archlinux.org/archlinux/packaging/packages/filesystem/-/issues/7 which seem little related.

Correct me if I'm wrong, but my understanding is Arch doesn't want to ship inetutils in core/by default anymore.
But I assume that inetutils would still be possible to install (just not installed by default), right?
And I guess in their CI they noticed the CRuby tests (specifically ruby/spec) doesn't pass without hostname.
The only way to fix their CI fast and for existing CRuby releases is to add inetutils (or some other impl of hostname, if both Debian and Fedora do it, probably there is a good reason to do it, I would think ruby/spec is hardly the only usage) as a test dependency of the Arch ruby package.
Have they done that?
If yes, why do they consider that not enough, are they planning to remove the possibility to install hostname on Arch?

In any case backporting here only solves the problem when there is a release of 3.3/3.4, which seems to have very little value if they need to keep hostname while running tests until then anyway.

[Eregon (Benoit Daloze)]

FWIW the older issue has a clear plan which would cause no breaking changes: https://bugs.archlinux.org/task/27808
The new issue is just unclear about everything from what I see.

[Eregon (Benoit Daloze)]

@ioquatix (Samuel Williams) There are several problems with what happened here, so I'll list them in the hope this does not repeat in the future:

• The rationale for this change is not well explained (e.g. why is it a problem for Arch to have inettools/"another hostname impl" as a test dependency of the Ruby package?). It's not OK to ask people to read various issues on some other bug tracker (takes a lot of time), the rationale should be expressed directly in the PR or issue description, clearly.
• You merged 2 PRs without waiting for review, and there were issues with both PRs. Reviewing after it's merged is a lot more time-demanding and frustrating (for both sides).
• Instead, you wrote on the CRuby Slack #general channel for this (IMO too small matter to spam general for this), but the PR was already merged when I could see it. Having the split discussion in 3 places is also wasting more time. Instead, ask one or a few reviewers to review the PR, and wait for one review.
• The PR should ideally be to https://github.com/ruby/spec directly, then it would be clear you need a ruby/spec maintainer review.
• It would be best if the Arch maintainer would make the PR or issue themselves, they know the rationale best and then if there is any question they can easily be asked. You are playing messenger here and that's slowing things down and losing information.
• I know you are well intentioned and are trying to help Arch maintainers here, but the net result is frustration at least on my side, lots of time wasted, a brittle/broken spec and still no clear reason for this extra complexity.
  Hopefully those concerns will be solved on https://github.com/ruby/ruby/pull/12655 and the next PR, if not I will revert both PRs and then it can be done the proper way from the start, which should be better for everyone involved.

[k0kubun (Takashi Kokubun)]

• Backport changed from 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED, 3.4: REQUIRED to 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED, 3.4: DONE

ruby_3_4 feb4a688a24a1966c8d08962a1104001234efcae merged revision(s) 46b544c54955348ef1ea9692b837b061f59f91cd, d3abee739f4feb91bb9aaae33877d70c8c576db0.