Is there a way to prevent a particular gem from being updated by gem update?

byrnejb's Avatar


24 Jun, 2010 01:28 PM

My OS is CentOS-5.5. The upstream provider stabilizes packages to provide long term support. Recently, a gem author upgraded a gem in a point release in such a way as to brake compatibility with the vendor supplied package. The proposed solution is to upgrade the vendor's package. That is not an option for this system. Nor is removing the gem since we need its functionality to support ActiveWarehouse-ETL.

We run gem update on a regular basis and the problem that this situation causes is that we now have to run gem outdated and then update gems individually to get around this one item. Is there any way to turn off automatic updates for specific gems so that we can return to just running gem update?

  1. Support Staff 1 Posted by Nick Quaranto on 24 Jun, 2010 11:59 PM

    Nick Quaranto's Avatar

    Not really, the best thing you could probably do is lockdown your environment so you don't have that gem installed, or just update gems you're using specifically.

    What gem is causing the breakage? Maybe we could get a hold of the author to notify them.

  2. 2 Posted by byrnejb on 25 Jun, 2010 01:21 PM

    byrnejb's Avatar

    The problem is with sqlite3-ruby.-1.3.0 The author has been notified. His answer is that our version of sqlite3 is too old. Which is perfectly true and will not be altered .

    We need an sqlite3 adapter to enable ActiveWarehouise-ETL. I am perfectly content to stay on 1.2.5 but we have a number of other gems, notibly passenger, rails, rack, devise, cucumber, etc. which need to be updated fairly frequently. Going though a long list of gem updates by hand on multiple systems is a bit tiresome.

    My current idea is to simply remove (uninstall <- strange word to use) the sqlite3-ruby gem, run the update, and reinstall the particular version of sqlite3-ruby that we use. I suppose that bundler is meant to address this very issue so I guess I will try that route first.

    That this issue revolves around a point release is a bit problematic from my standpoint. I should think that any update the breaks backwards compatibility should have a change to the major revision number.

    In this regard, an enhancement that I would like to suggest is that Ruby-Gems should not 'update' gems that have a major revison number change, or at least provide a switch (--safe) to optionally enable this functionality. In this scenario a 'gem update' would update minor revsions and patches as now but only notify that an 'install' of a major revsion number update is required when one is detected. An advantage to this approach is that gem authors could then maintain parallel updates to two streams of a single gem family (Rails-3 and Rails-2 for instance) and these would not clash. So, if someone only had Rails-2 installed then Rails-3 would not be automatically added. I suppose this would also require a --quiet switch to turn off unwanted notifications.

    Thanks for the help.


  3. Support Staff 3 Posted by Eric Hodel on 06 Jul, 2010 08:34 PM

    Eric Hodel's Avatar

    This looks like a good place to use a solution like isolate or bundler to manage gem versions.

  4. byrnejb closed this discussion on 12 Oct, 2010 07:46 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac