ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: shevegen@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:92388] [Ruby trunk Bug#15787] rubygems.rb on read-only volume
Date: Tue, 23 Apr 2019 22:47:58 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-77743.20190423224757.2718a1e60603f6a3@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15787.20190423193920@ruby-lang.org

Issue #15787 has been updated by shevegen (Robert A. Heiler).


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 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 particular 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 you been the haiku
users who tried to get ruby to work in the past on haiku?), so I would classify this as a 
regression (since it worked before), although I think none of this was deliberate - 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.

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 particular because
there is indeed no trivial way to change the read-only situation. And I think the ruby team
wants to have ruby work on as many different operating systems as is reasonable possible, so
it seems reasonable to assume that there is an interest in resolving the problem 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 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.

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án 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 read-only.

Issue: Ruby has to maintain a list of installed gems in a single file, in rubygems.rb. Ruby stats this file, and bails out if it is read-only:

```
~ » ruby --version
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-haiku]
~ » ruby
Traceback (most recent call last):
        1: from <internal:gem_prelude>:2:in `<internal:gem_prelude>'
<internal:gem_prelude>:2:in `require': Operation not supported -- /boot/system/lib/ruby/2.6.0/rubygems.rb (LoadError)
~ » ls -la /boot/system/lib/ruby/2.6.0/rubygems.rb
-r--r--r-- 1 user root 36970 márc.  6 10:01 /boot/system/lib/ruby/2.6.0/rubygems.rb
~ » 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 problem. 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 writeable folderstructure) and hope it won't get out of sync when pkgman (package updater software) updates Ruby packages, or it has to be fixed to enumerate 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 "rubygems.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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

  parent reply	other threads:[~2019-04-23 22:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15787.20190423193920@ruby-lang.org>
2019-04-23 19:39 ` [ruby-core:92386] [Ruby trunk Bug#15787] rubygems.rb on read-only volume zmizsei
2019-04-23 22:47 ` shevegen [this message]
2019-04-24  6:51 ` [ruby-core:92396] " zmizsei
2019-04-24 13:47 ` [ruby-core:92398] " wishdev
2019-04-24 17:48 ` [ruby-core:92401] " zmizsei
2019-05-03 16:36 ` [ruby-core:92535] " zmizsei
2019-05-05 10:15 ` [ruby-core:92549] " zmizsei
2019-05-05 14:08 ` [ruby-core:92551] [Ruby trunk Bug#15787] LoadError by EPERM " nobu
2019-05-05 15:57 ` [ruby-core:92555] " zmizsei

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-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-77743.20190423224757.2718a1e60603f6a3@ruby-lang.org \
    --to=ruby-core@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 read-only IMAP folder(s) and NNTP newsgroup(s).