On 3/28/20 11:37 AM, l0f...@tuta.io wrote: > Hi, > > I'm on Debian 10. > What is the best practice regarding Ruby gems installation please (user vs > root)? > Below is my situation. > > It all begins with the installation of vim-gtk3 (because I want access to the > +/* registers) that comes with the following dependencies: > libruby2.5 rake ruby ruby-did-you-mean ruby-minitest ruby-net-telnet > ruby-power-assert ruby-test-unit ruby-xmlrpc ruby2.5 rubygems-integration > <skip> > > So my question about the best practice at the very beginning. > I think it can be very tricky to have parallel versions of the same gems, and > I don't think having obsolete user gems is really nice (security+features). > How do you manage that situation? Do you delete all user local gems and only > keep root's (maybe it introduces access errors in your programs by doing so)? > Do you change the gem directories permissions (maybe it's less secure...)? > Don't you touch anything and just use sudo everywhere? Other idea? > > PS: I fiddled so much with my installation last day that I even lost access > to my local gems... <skip> > Many thanks in advance :)Best regards, > l0f4r0 >
In order to avoid messing up packages and system in general one should never install modules/packages/whatever as root into system locations. Most of sane languages provide a way to install modules into home directory and usually these locations have higher precedence when loading modules or one can tell the language to load the modules from the defined location first. I don't know about Ruby, but in Debian you get only a subset of all possible modules for the language of your choice. And it is very likely that in Debian stable they are old and even might be too old for some specific software. So in my opinion the way to go is to use available packages from Debian and install the missing one locally. However if you like to install the software the Debian way you might consider using tools like dh-make-ruby to create debian packages from a ruby library and install it later as a local debian package with dpkg. This way has a number of benefits, but of course it may not work for complicated libs or for a project where you need to get tens of hundreds of not-yet-packaged libs. Regarding the security of the packages in Debian stable, if the package has a known vulnerability it is very likely that the security team will take care and fix the package. So this is not an issue. Regards, Alex
