From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3D70E1F4BE for ; Mon, 21 Oct 2024 09:13:27 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=oiQ/qBRF; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=Fhdcd6Qs; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1729502004; bh=AA5keyrxYSjWBnbRdvpjLk/PzIGxYVvMgPjTI56zcZI=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=oiQ/qBRFUjcunAZnxmppt3Ab0ssi58IIXJk6Rod4pKPk13/CzbE6fjzHEqpAaqb/s 9Gc69w2Mjlq3erfK8rzQnzPL3MyFQh3ATRK7NgQ+fqZHaLmKDSEyiuCOJ5Bomv49EJ Z+NsmtYH78CInqu5PcpNoBJ8shatFCTHsZMrxBiA= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id EDAAE448C1 for ; Mon, 21 Oct 2024 09:13:24 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=Fhdcd6Qs; dkim-atps=neutral Received: from s.wfbtzhsv.outbound-mail.sendgrid.net (s.wfbtzhsv.outbound-mail.sendgrid.net [159.183.224.104]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 84E7F4454A for ; Mon, 21 Oct 2024 08:50:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=JePJOkiRp+J2Y/0UAxZaGrEJC6nH6csydwSF1BnH5go=; b=Fhdcd6Qso6WIfq21MRV4lVXzM6VCLnC1kWMqzMNdeX8H9Z+Z+1RJHbRLGFVuVd3AG6/M tVT+sfKktlNFTZBsNjE2qrHQKqBcT+C8O3aJK4yg6SHScImykiajshTraZ/iUoMa1zeCpQ 4EKd/Lv+7ongCBm75F+IWjWGabjOrrRdOw0idcpZbu1t42/04f6AamawoigeTqcvp8MMnK fgaj3jTTiW8EuFi/hpxN+epn5g4tyweqg2G7OnWsXvUrzyCr3SsrZ1ICgvEPRlkNQU5c3w /N9R3FD4DfE5bKG031sDTaaY1FblX4wb6s7f6OKsrn0jAtOfwIcMKvZ7SzTMLvDg== Received: by recvd-7cc7f7d978-762fg with SMTP id recvd-7cc7f7d978-762fg-1-671615CF-16 2024-10-21 08:50:23.633877072 +0000 UTC m=+3336846.778824103 Received: from herokuapp.com (unknown) by geopod-ismtpd-3 (SG) with ESMTP id _ynXM4buSKGVVvmZLWTxag for ; Mon, 21 Oct 2024 08:50:23.615 +0000 (UTC) Date: Mon, 21 Oct 2024 08:50:23 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20800 X-Redmine-Issue-Author: vo.x X-Redmine-Issue-Priority: Normal X-Redmine-Sender: vo.x X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 96194 X-SG-EID: =?us-ascii?Q?u001=2EyMiCBSACWrWmffOKyGXWHegF7vzERB8YDC=2Fl8bL1VoJCfzjoEQKqqhWMB?= =?us-ascii?Q?cCIxOU5CxEWLdUTISPq9d+vx=2FmMei1h+vxeB7Sf?= =?us-ascii?Q?YJlTdY78MsGEjVhYKFVfJIR78wPj6JVbakv+MBH?= =?us-ascii?Q?23Ke=2FQjhDlCPFYrgVeXhmmx7iyYuiph0ZKnsGgy?= =?us-ascii?Q?90HzwTO9j=2F=2F4sPIyJRhqPE7qM+WFw+65a=2F1thV7?= =?us-ascii?Q?0Ok8U1Pf5IE+5+ngv4oMk=2FJxMUozB5ssZzkawLJ?= =?us-ascii?Q?X9+q?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: 3XW2OWQHAFGDCSKEWQA2WTKCIJIOYDLI X-Message-ID-Hash: 3XW2OWQHAFGDCSKEWQA2WTKCIJIOYDLI X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119560] [Ruby master Bug#20800] Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin` List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "vo.x (Vit Ondruch) via ruby-core" Cc: "vo.x (Vit Ondruch)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20800 has been updated by vo.x (Vit Ondruch). > but using --enable-multiarch when not multiarch seems like a misuse of the feature. I don't disagree. If I had other option, I'd use it. If somebody is interested to help, I'll gladly open separate ticket to share what are my thoughts on this topic. > can you explain where you'd like it to place ruby? It is hard to guess what was the reason for [1] (and actually that should be the content of PR / commit message. Can this be improved, please?). So to me, it is questionable why the `/usr/libexec/` + symlink are used on the first place. But given this is reasonable change, then the patch should be likely `/usr/libexec/x86_64-linux/ruby`. At least this is my interpretation of FHS [2] and that would be aligned with what is the standard on Fedora (although admittedly, we would also leave out the `x86_64-linux`, because Fedora is not multilib). BTW I also don't understand why if usage of `/usr/libexec/` + symlink was deemed useful, why it should be mulitilib only. [1]: https://github.com/ruby/ruby/pull/10010 [2]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html ---------------------------------------- Bug #20800: Don't place `ruby` executable into `/usr/libexec/x86_64-linux/bin` https://bugs.ruby-lang.org/issues/20800#change-110175 * Author: vo.x (Vit Ondruch) * Status: Open * 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/