Re: Best practice regarding Ruby gems installation on Buster
Andrei,
28 mars 2020 à 16:46 de andreimpopescu@gmail.com:
> On Sb, 28 mar 20, 15:57:57, l0f4r0@tuta.io wrote:
>
>> Actually, I'm totally OK with the approach.
>>
>> But I'm not really talking about the ruby2.5 package and its
>> dependencies here. I don't need a specific higher Ruby version
>> (framework, engine...) so the Debian stable Ruby package fits my
>> needs.
>>
>> I'm rather talking about Ruby gems themselves. If I'm right, Buster
>> seems to come with some gems installed by default with ruby2.5 but
>> they are obsolete now.
>>
> What makes you think that?
>
Because some of my aforementioned local gems seems to come with ruby2.5:
$ dpkg -S {cmath,fiddle,psych}.rb
libruby2.5:amd64: /usr/lib/ruby/2.5.0/cmath.rb
libruby2.5:amd64: /usr/lib/ruby/2.5.0/fiddle.rb
libruby2.5:amd64: /usr/lib/ruby/2.5.0/psych.rb
For example, I did manage to update psych via "gem update" but on the same time Debian told me all my packages were up to date...
>> As they could introduce a security risk for example, I just want to
>> update them.
>>
> It seems to me that you don't have a specific reason to update them,
> just a "there's a newer version available and I want to update" itch,
> also known as "versionitis" :)
>
I agree with you, it's a temptation but 1) I was speaking of potential security issues (I don't have any clue but there could be some I presume - I didn't check the changelog I confess) 2) I'm running Buster so I'm not so versionitis-ill ;)
>> However updating seems to be less straightfoward than anticipated
>> hence my request for advice ;)
>>
> Everything I wrote still applies. Unless otherwise specified Debian
> provides security support for all gems distributed as Debian packages.
> If you install your gems outside the Debian package manager you are on
> your own.
>
Ok, I didn't realize that at the beginning!
My gems must have been installed by other packages/dependencies...
So you are telling me to let Debian deal with its Ruby gems alone while I focus on my specific additional gems not provided by Debian packages?
If true, it means that Debian packages come with some Ruby gems, Debian provides support for them but user has in fine the possibility to update them inside Ruby (gem update) but by doing so (s)he lose Debian support. It would make sense...
Let's talk about my next step please. I would like now to install fusuma gem (https://github.com/iberianpig/fusuma). It's not provided by any Debian package.
I know i's gonna work with "gem install" but after that (and let's imagine 4 months later I have 20 other gems installed), how can I make a difference in my local gems between those manually installed gems that I want to keep updated and my Debian provided gems that I don't want to update to keep Debian support?Indeed, it would be really easy to go off-trail with a simple 'gem update' (and I don't want to specify my all 20 gems after 'gem update') ;)
Best regards,
l0f4r0
Reply to: