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 <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:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>