Personally for me its no issue. Because with rvm I can upgrade to
1.3.6 with no issue. But here are a couple of ideas.
These are not particularly well thought out solutions. Perhaps irc on
#rubygems and they might suggest something else.
What about the script you can add for compiling stuff ? It might be
possible to put in there a check to detect whether the installed
rubgems can be upgradable to 1.3.6 (or at least whether its the
modified debian version). Then can print such a warning message
accordingly for those cases. Of course, the merb 1.1x might still get
installed, depending what you want to do at that point. Perhaps from
that entry point its too late to re-write or modify the .gemspec file
to roll back the merb dependency.
A warning message could at least inform the user how to install chef
with merb 1.0.x. Of course the drawback with only printing a warning
message is that its not going to be apparent for those admins who are
doing automated installs, and may not see the message. Alternatively
you might want to abort the install / refuse to finish installing the
Otherwise, some projects, like haml publish an ‘edge’ version of their
gems. So if you are prepared for that extra burden, it might be
possible to make a secondary release, which just has a slightly
different gemspec / gem-deps?
This other gem package could be published to rubygems under a
different name (eg like ‘haml’, and ‘haml-edge’ have done). Or if you
dont want to publish under 2 different names when one of them would
have to be “download only” .gem file published from opscode servers.
Then the warning message should be directing people to install the gem
from direct http url download.
On Tue, Apr 27, 2010 at 1:36 AM, Daniel DeLeo email@example.com wrote:
I’d like to get your feedback about a problem we’re facing with
supporting merb 1.1.0. This issue will only affect users installing
from rubygems. Users installing from apt or yum/RPM will not be
The issue is that Merb 1.1.0 depends on bundler. Bundler depends on
rubygems 1.3.6. Many platforms do not have rubygems 1.3.6 available in
their package repos, and some explicitly disable the ‘gem update
As far as I can tell, there is no way for us to specify a dependency
on merb 1.0.x but also allow users to opt in to merb 1.1.0 when
installing via rubygems.
If we modify our gem merb dependency to allow merb version 1.1.x, then
users will get merb 1.1.0 when installing. If they have a rubygems
version less than 1.3.6, this installation will fail when it attempts
to install bundler. I am not sure what the behavior is if merb 1.0.15
is already installed, but if it tries to upgrade, it’s possible that
the shortest path to success would be to reinstall rubygems from
So, I’d like to know if you all feel it’s reasonable to "require"
users installing from gems to upgrade rubygems to version 1.3.6, or if
you know of an elegant (or ugly!) solution to this problem. Ideally,
we’d like to make merb 1.1 opt-in until the rubygems situation
improves, but merb 1.1 support is a blocker for ruby 1.9 support for
us, so we’d like to support it asap.
As a side note, I’ve pushed a development branch with merb 1.1 support
to my github:
If you’re comfortable running a development branch, please try it out.
Report any bugs you find as comments on this ticket: