ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
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:120422] [Ruby master Bug#20800] Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
Date: Thu, 26 Dec 2024 20:19:21 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-111202.20241226201921.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).


As far as I can tell, the binaries in Debian are placed in `/usr/bin`:

https://packages.debian.org/sid/amd64/ruby3.3/filelist

I would expect that if this was problem, Debian folks would carry downstream patch adjusting this location and this change would refer to that patch or some other request from Debian with more details.

Generally, I still don't understand motivation for such change. From my POV, with my Fedora maintainer hat on and with all due respect, Ruby upstream should mostly care about installing Ruby into some dedicated directory out of system locations. Practice of running `make install` and modifying content of `/usr` should be discouraged. Installing into `/usr/local` is a bit better option, but then who cares about `multiarch`, there?

----------------------------------------
Bug #20800: Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin`
https://bugs.ruby-lang.org/issues/20800#change-111202

* 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/

  parent reply	other threads:[~2024-12-26 20:20 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 ` vo.x (Vit Ondruch) via ruby-core [this message]
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-111202.20241226201921.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).