[ruby-core:92388] [Ruby trunk Bug#15787] rubygems.rb on read-only volume

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 <internal:gem_prelude>:2:in `<internal:gem_prelude>'
<internal:gem_prelude>: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: <mailto:[e-mail]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>