On Sb, 28 mar 20, 18:28:53, l0f4r0@tuta.io wrote: > 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: > > 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... That still doesn't make it obsolete ;) > >> 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) Any *known* security issues should be fixed via the regular update mechanism (provided you have Debian security repository in your sources.list). > 2) I'm running Buster so I'm not so versionitis-ill ;) There's nothing wrong with running other Debian releases as long as you understand the risks and know how to cope with the issues. > 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? Yes. > 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... In general it's not a good idea to let two different package managers update the same piece of software. > 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') ;) See Dan Purgert's reply, it provides a method for keeping Debian and locally installed gems separated. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature