Re: Best practice regarding Ruby gems installation on Buster
> 28 mars 2020 à 18:18 de amestia@rsh2.donotuse.de:
>
>> 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.
>>
> So you would suggest not to mess with Debian ruby gems (except updating them through their corresponding packages with 'apt update' sometimes) and install those that don't have any package on Debian ecosystem for the local user only?
Exactly. If needed you can of course install them system wide, but
somewhere in /usr/local for example so they don't overlap with existing
structure for Debian packages. But see dh-make-ruby first if you'd like
to go this way.
> If true, I think this is the goal of the following command:
> $ gem install --user-install GEMNAME
Looks good, but since I don't use ruby I can't tell you exactly.
>
> So when I want to install a ruby gem, my reflex should be first to verify if Debian already provides it in one of its packages?
> * If Debian provides the gem and its (probably old) version fits my need => install the Debian package ('apt install')
> * If Debian provides the gem but I want a brand new version OR if Debian doesn't provide the gem at all => install the gem ('gem install --user-install')
> It makes sense?
That's what I would do. However the second option is more complicated. A
dependency of a package will be installed even if you would like to have
more recent gem. Which mean that you might end up in a situation where
the same rubygem comes from Debian and locally as more up-to-date
version. But in this case the local version should have higher
precedence for local projects.
Ruby also provides rvm - Ruby Version Manager, in some cases it totally
make sense to start with a self-contained envs. After all it all depends
on what you'd like to do, but using sudo to overwrite modules in system
locations is plain wrong in my opinion and breaks the system.
>> 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.
>>
> Ok, I get it now with Andrei's answer as well.
> I thought initially that Debian only provides ruby engine/framework, not packages containing ruby code as well ;)
There are many packages using ruby and it's modules, so if a software
package depends on some ruby gems, they need to be packaged too.
But that's the cool thing about Debian and binary packages, one can
simply run apt-get install to get a complicated software installed.
>
> Best regards,
> l0f4r0
>
Best,
Alex
Reply to: