From: "mame (Yusuke Endoh) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "mame (Yusuke Endoh)" <noreply@ruby-lang.org>
Subject: [ruby-core:120419] [Ruby master Bug#20800] Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
Date: Thu, 26 Dec 2024 14:35:04 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-111200.20241226143503.703@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20800.20241017082432.703@ruby-lang.org>
Issue #20800 has been updated by mame (Yusuke Endoh).
The motivation is very clear, at least to me: The word “multiarch” seems to mean installing architecture-dependent files in separate arch-named directories; and "ruby" executable is architecture-dependent; it should be installed to any arch-named directory.
But to my surprise, https://wiki.debian.org/Multiarch/HOWTO says:
> Note that it does not enable multiple architecture versions of **applications** to be installed simultaneously.
So "multiarch" only applies to libraries and not to applications (i.e., executables)? If so, what a confusing and bad name "multiarch" is!
The name argument aside, you expect that the “ruby” executable to be installed into `$PREFIX/bin` by default, even though it is arch-dependent, right?
----------------------------------------
Bug #20800: Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
https://bugs.ruby-lang.org/issues/20800#change-111200
* Author: vo.x (Vit Ondruch)
* Status: Closed
* ruby -v: ruby 3.4.0dev (2024-10-15 master 3da3cabf98) +PRISM [x86_64-linux]
* Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
Trying to prepare Ruby 3.4 package for Fedora, it seems that since [1], the `ruby` executable is installed into `/usr/libexec/x86_64-linux/bin`:
~~~
installing binary commands: /usr/libexec/x86_64-linux/bin
~~~
Unfortunately, the PR does not explain anything about reasons why. To me, using `libexec` is surprising, because according to FHS [2], the directory is for internal binaries. What is even more surprising is usage of the `bin` subdirectory there, which IMHO does not follow any standard or convention (I don't have `/usr/libexec/x86_64-linux/bin` directory on my Fedora yet).
Just FTR, these are the configuration options used:
~~~
/builddir/build/BUILD/ruby-3.4.0_20241016git3da3cabf98-build/ruby-3.4.0-3da3cabf98/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-rubylibprefix=/usr/share/ruby --with-archlibdir=/usr/lib64 --with-rubyarchprefix=/usr/lib64/ruby --with-sitedir=/usr/local/share/ruby/site_ruby --with-sitearchdir=/usr/local/lib64/ruby/site_ruby --with-vendordir=/usr/share/ruby/vendor_ruby --with-vendorarchdir=/usr/lib64/ruby/vendor_ruby --with-rubyhdrdir=/usr/include --with-rubyarchhdrdir=/usr/include '--with-sitearchhdrdir=$(sitehdrdir)/$(arch)' '--with-vendorarchhdrdir=$(vendorhdrdir)/$(arch)' --with-rubygemsdir=/usr/share/rubygems --with-ruby-pc=ruby.pc --with-compress-debug-sections=no --disable-rpath --enable-mkmf-verbose --enable-shared --with-ruby-version= --enable-multiarch --enable-yjit
~~~
The `--enable-multiarch` is among the options. It is used not because Fedora would be `multiarch`, but because it provides the highest flexibility.
[1]: https://github.com/ruby/ruby/pull/10010
[2]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
--
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/
next prev parent reply other threads:[~2024-12-26 14:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 8:50 [ruby-core:119534] " vo.x (Vit Ondruch) via ruby-core
2024-10-21 8:50 ` [ruby-core:119539] " alanwu (Alan Wu) via ruby-core
2024-10-21 8:50 ` [ruby-core:119560] " vo.x (Vit Ondruch) via ruby-core
2024-10-21 9:01 ` [ruby-core:119563] " vo.x (Vit Ondruch) via ruby-core
2024-11-14 16:05 ` [ruby-core:119931] " vo.x (Vit Ondruch) via ruby-core
2024-12-26 8:33 ` [ruby-core:120416] " sorah (Sorah Fukumori) via ruby-core
2024-12-26 14:35 ` mame (Yusuke Endoh) via ruby-core [this message]
2024-12-26 20:19 ` [ruby-core:120422] " vo.x (Vit Ondruch) via ruby-core
2024-12-26 22:46 ` [ruby-core:120427] " mame (Yusuke Endoh) via ruby-core
2024-12-27 10:16 ` [ruby-core:120429] " vo.x (Vit Ondruch) 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-111200.20241226143503.703@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).