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.5 required=3.0 tests=AWL,BAYES_00, 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 180CB1F453 for ; Wed, 24 Apr 2019 06:51:45 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id EA804120BA5; Wed, 24 Apr 2019 15:51:39 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 39391120BA5 for ; Wed, 24 Apr 2019 15:51:36 +0900 (JST) Received: by filter0077p3mdw1.sendgrid.net with SMTP id filter0077p3mdw1-26138-5CC00778-10 2019-04-24 06:51:36.451419322 +0000 UTC m=+132165.589724903 Received: from herokuapp.com (unknown [54.210.50.214]) by ismtpd0029p1iad2.sendgrid.net (SG) with ESMTP id NvUomjU0QMijMNpWtS2odw for ; Wed, 24 Apr 2019 06:51:36.307 +0000 (UTC) Date: Wed, 24 Apr 2019 06:51:36 +0000 (UTC) From: zmizsei@extrowerk.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 67879 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15787 X-Redmine-Issue-Author: extrowerk X-Redmine-Sender: extrowerk 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?=2Fdp7rojWUFaulpcwB2EwWIzUzLr6WwrWraSpLm61wGq0ExPdUrWGjNOS7aDS5l?= =?us-ascii?Q?Sj8TEmpuSfZTcr=2FN1dCEy0sYS84zuYYvdcqVPaT?= =?us-ascii?Q?KrUhaZXREBFfekCth49dvDibjYlzXTYOWwvK7Nl?= =?us-ascii?Q?rofEMtadxh3AyumubmGz9E6ZdQ2y+7yIjXYWv28?= =?us-ascii?Q?=2F6VQvSSZ6+uNXbaDh4hSZyzMaF4=2Fo6+ZLjg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92396 Subject: [ruby-core:92396] [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 extrowerk (Zolt=E1n Mizsei). shevegen (Robert A. Heiler) wrote: > This is indeed unfortunate but I guess the code could be changed. Keep in= mind that the ruby core > team probably has not that much experience with haiku - most will use lin= ux or mac OSX, some = > windows or one of the BSDs. I know, this is why i am here :) Our ruby port is way too old and needs to = be updated, but for that this issue have to be solved first. > You mentioned that the behaviour in 2.2.x was different (by the way, have= you been the haiku > users who tried to get ruby to work in the past on haiku?), so I would cl= assify this as a = > regression (since it worked before), although I think none of this was de= liberate - there are > not that many heroic haiku users out there. For --userinstall, typically = the home directory > is writable for the user, so that should work fine. Yep, in 2.2.x there were no problem on Haiku, according the 2.2.10 sources = (in ruby.c) it was not checked if the file is RO. So for us it is a regress= ion, but maybe it is required or logically needed. Beside other HaikuPorts team members i also worked on ruby in the past ( ht= tps://github.com/haikuports/haikuports/pulls?utf8=3D%E2%9C%93&q=3Dis%3Apr+a= uthor%3Aextrowerk+ruby+ ), but i only use it for jekyll, so forgive me if i= make logical mistakes or doesn't understand the importance of some code-bl= ocks, maybe they are required in production. I know about --userinstall, this is the workaround what i see everywhere on= the internet as workaround, but it doesn't solves the problem for us, as r= uby checks the rubygems.rb before starting to doing anything and it bails o= ut even with --userinstall on Haiku. > Perhaps your issue is related to both rubygems, and ruby.c; I believe tha= t the ruby core team > and the rubygems team will be sympathetic to the described problem, in pa= rticular because > there is indeed no trivial way to change the read-only situation. And I t= hink the ruby team > wants to have ruby work on as many different operating systems as is reas= onable possible, so > it seems reasonable to assume that there is an interest in resolving the = problem at hand. We are also definetely interested to have an up to date ruby port in our pa= ckage manager. > I think what might help most is if you could suggest what changes you wou= ld 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 hacki= sh work around = > for locations could always be an environment variable, but I am not sure = how 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. I tried to fix it earlier ( https://github.com/haikuports/haikuports/pull/7= 00 ), it just disables the check, but the HaikuPorts team was not amused, s= o we never merged this change, however it worked for me. Consider the following: - some programs using ruby and needs some ruby gems installed. To the packa= ge_daemon be able to fullfill the dependencies, we have to package the gems= as we do for the python modules, as it cannot just "gem install" things (v= ersion constraints, know-working versions, etc), so if a user installs the = program it will guaranteed to work. Thus we will install some gems in syste= m folders, they will be read-only, of course. - the user must be able to install gems trough "gem" too. They will be inst= alled in the home folder. The system and user gems needs to be enumerated at start, at least both loc= ation have to be searched for the imported gems. For this we can use the ve= ndor/sites folders AFAIK. Now 2 questions: - what if the same gem installed as system and as user too? Maybe even diff= erent versions? Does ruby picks automatically the never one? I am pretty su= re it is handled somehow already in ruby. - Does rubygems.rb needs to be writeable at all? * If it needs to be writeable, then is it possible to add a user-specific "= rubygems.rb" to override/extend the system one? If so, how is it handled on= other platforms? * If not, then i don't know, why does ruby checks for it. > What happens when ruby is upgraded on haiku, say versions 2.6.3 to versio= n 2.7.0 or = > like that? I am not sure if i understand this question. Currently the system gems inst= alled to " **/boot/system/lib/ruby/gems/2.6.0** " which is read only, while= the user gems installed to "$HOME/.gems/ruby/2.6.0" (i plan to change it l= ater, on Haiku there should be no dot-folders in the home, and nothing shou= ld place any configuration/settings files directly into $HOME, it makes a m= ess. The plan is to move them to either **/boot/system/non-packaged/lib/rub= y/gems/2.6.0** or to **/boot/home/config/non-packaged/lib/ruby/gems/2.6.0**= , as we do it for python. This folders are writeable. Then if ruby gets upgraded it won't find the gems installed for the previou= s version, but so we can even provide different ruby versions in the packag= e manager, as we do it for python (python2 and python3) I hope i answered your question. If something still unclear, feel free to a= sk me. ---------------------------------------- Bug #15787: rubygems.rb on read-only volume https://bugs.ruby-lang.org/issues/15787#change-77754 * 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: