From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 7274C1F453 for ; Tue, 23 Apr 2019 22:48:05 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D5253120B87; Wed, 24 Apr 2019 07:47:59 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 8332E120A32 for ; Wed, 24 Apr 2019 07:47:57 +0900 (JST) Received: by filter0126p3las1.sendgrid.net with SMTP id filter0126p3las1-21602-5CBF961E-5 2019-04-23 22:47:58.101661006 +0000 UTC m=+103047.301588596 Received: from herokuapp.com (unknown [52.90.207.227]) by ismtpd0065p1mdw1.sendgrid.net (SG) with ESMTP id 3O4UsmNpQSWpKSBloS-J2w for ; Tue, 23 Apr 2019 22:47:58.153 +0000 (UTC) Date: Tue, 23 Apr 2019 22:47:58 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67871 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15787 X-Redmine-Issue-Author: extrowerk X-Redmine-Sender: shevegen 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-SG-EID: =?us-ascii?Q?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0x+SRMueYhbXgvs=2FCZTWB?= =?us-ascii?Q?QKS4lHkpQ77LlRcuQiOWbBdgZk=2F6etcOXuuVpIH?= =?us-ascii?Q?ajcLtdv67j5OGmnIkkxi2fbO+7Uy=2FQzJPrk8h92?= =?us-ascii?Q?vzBQRVxSx6wbHiAnLKz69DpdNB=2F2bJECc=2FHFWZO?= =?us-ascii?Q?4Rj+2K5xAb2tNabKLFuYDQ3nTC9=2FO+4gGrQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92388 Subject: [ruby-core:92388] [Ruby trunk Bug#15787] rubygems.rb on read-only volume X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15787 has been updated by shevegen (Robert A. Heiler). This is indeed unfortunate but I guess the code could be changed. Keep in m= ind that the ruby core team probably has not that much experience with haiku - most will use linux= or mac OSX, some = windows or one of the BSDs. Your problem description reminds me a bit of the situation of gems, to some= extent, e. g. = where we can use --userinstall to install into the home directory (in parti= cular debian has this tendency to change target locations, e. g. /var/*). You mentioned that the behaviour in 2.2.x was different (by the way, have y= ou been the haiku users who tried to get ruby to work in the past on haiku?), so I would clas= sify this as a = regression (since it worked before), although I think none of this was deli= berate - there are not that many heroic haiku users out there. For --userinstall, typically th= e home directory is writable for the user, so that should work fine. Is this more related to how rubygems works, though? = Perhaps your issue is related to both rubygems, and ruby.c; I believe that = the ruby core team and the rubygems team will be sympathetic to the described problem, in part= icular because there is indeed no trivial way to change the read-only situation. And I thi= nk the ruby team wants to have ruby work on as many different operating systems as is reason= able possible, so it seems reasonable to assume that there is an interest in resolving the pr= oblem at hand. I think what might help most is if you could suggest what changes you would= consider to be best, in particular to (a) have it work for future versions of haiku and (b= ) to not break any other ruby installations (on other operating systems). A simple hackish= work around = for locations could always be an environment variable, but I am not sure ho= w well the ruby team knows haiku to know what will work to resolve this; this is why I= think the ruby team may prefer if you could give some recommendations. What happens when ruby is upgraded on haiku, say versions 2.6.3 to version = 2.7.0 or = like that? = ---------------------------------------- Bug #15787: rubygems.rb on read-only volume https://bugs.ruby-lang.org/issues/15787#change-77743 * Author: extrowerk (Zolt=E1n Mizsei) * Status: Open * Priority: Normal * Assignee: = * Target version: = * ruby -v: ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-haiku] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- On Haiku the package management just virtually extracts/populates the files= , and as it doesn't have write-overlay feature, the populated files are rea= d-only. Issue: Ruby has to maintain a list of installed gems in a single file, in r= ubygems.rb. Ruby stats this file, and bails out if it is read-only: ``` ~ =BB ruby --version ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-haiku] ~ =BB ruby Traceback (most recent call last): 1: from :2:in `' :2:in `require': Operation not supported -- /boot/sys= tem/lib/ruby/2.6.0/rubygems.rb (LoadError) ~ =BB ls -la /boot/system/lib/ruby/2.6.0/rubygems.rb -r--r--r-- 1 user root 36970 m=E1rc. 6 10:01 /boot/system/lib/ruby/2.6.0/r= ubygems.rb ~ =BB uname -a Haiku shredder 1 hrev53091 Apr 22 2019 22:17:21 x86_64 x86_64 Haiku ``` = The 2.2.x branch was not affected, but since 2.3 every version have this pr= oblem. Happens here: https://github.com/ruby/ruby/blob/trunk/ruby.c#L2098 Either it has to create this file somewhere in non-packaged (this is the wr= iteable folderstructure) and hope it won't get out of sync when pkgman (pac= kage updater software) updates Ruby packages, or it has to be fixed to enum= erate them directly by examining the directories. The fact that this file is located in a packaged tree also hints that Ruby = will probably want to also use packaged location for manual gems installs, = which obviously won't work either. Question: is it possible to force/instrument ruby to use a user-specific "r= ubygems.rb" if the system one read only? Probably this problem exists on other platforms too, where the user doesn't= have write-right to this file. How is it handled? Thank You! -- = https://bugs.ruby-lang.org/ Unsubscribe: