From: "vo.x (Vit Ondruch) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "vo.x (Vit Ondruch)" <noreply@ruby-lang.org>
Subject: [ruby-core:120429] [Ruby master Bug#20800] Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
Date: Fri, 27 Dec 2024 10:16:30 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-111208.20241227101628.703@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-20800.20241017082432.703@ruby-lang.org>
Issue #20800 has been updated by vo.x (Vit Ondruch).
What I actually want is the configuration options to be honored. If there is used `--bindir=/usr/bin` configuration option, then simply place binaries into that directory (IOW with that option, I expect `/usr/bin/ruby` to be created), don't do any additional modifications to it. Currently, there are still additional logic [1] under which is the destination modified. If there is no `--bindir` specified, then I don't really mind about the result that much.
[1]: https://github.com/ruby/ruby/blob/adbbc9109ee71848204b5168a7c1bf604849e5fa/tool/rbinstall.rb#L369-L371
----------------------------------------
Bug #20800: Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
https://bugs.ruby-lang.org/issues/20800#change-111208
* 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/
prev parent reply other threads:[~2024-12-27 10:16 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 ` [ruby-core:120419] " mame (Yusuke Endoh) via ruby-core
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 ` vo.x (Vit Ondruch) via ruby-core [this message]
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-111208.20241227101628.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).