ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "Eregon (Benoit Daloze)" <noreply@ruby-lang.org>
Subject: [ruby-core:120849] [Ruby master Bug#21095] Prefer `uname -n` over `hostname` in tests.
Date: Fri, 31 Jan 2025 09:54:22 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-111725.20250131095421.3344@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-21095.20250128213823.3344@ruby-lang.org>

Issue #21095 has been updated by Eregon (Benoit Daloze).


@ioquatix 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.

----------------------------------------
Bug #21095: Prefer `uname -n` over `hostname` in tests.
https://bugs.ruby-lang.org/issues/21095#change-111725

* Author: ioquatix (Samuel Williams)
* Status: Closed
* Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: REQUIRED, 3.4: REQUIRED
----------------------------------------
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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/

  parent reply	other threads:[~2025-01-31  9:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 21:38 [ruby-core:120811] " ioquatix (Samuel Williams) via ruby-core
2025-01-28 21:39 ` [ruby-core:120812] " ioquatix (Samuel Williams) via ruby-core
2025-01-28 21:58 ` [ruby-core:120813] " Eregon (Benoit Daloze) via ruby-core
2025-01-28 22:12 ` [ruby-core:120814] " ioquatix (Samuel Williams) via ruby-core
2025-01-29  9:34 ` [ruby-core:120820] " Eregon (Benoit Daloze) via ruby-core
2025-01-29 10:37 ` [ruby-core:120822] " Eregon (Benoit Daloze) via ruby-core
2025-01-29 10:39 ` [ruby-core:120823] " Eregon (Benoit Daloze) via ruby-core
2025-01-31  9:54 ` Eregon (Benoit Daloze) via ruby-core [this message]
2025-02-14  5:12 ` [ruby-core:121026] " k0kubun (Takashi Kokubun) via ruby-core
2025-03-08  9:20 ` [ruby-core:121268] " nagachika (Tomoyuki Chikanaga) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-111725.20250131095421.3344@ruby-lang.org \
    --to=ruby-core@ml.ruby-lang.org \
    --cc=noreply@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).