[Rubygems-developers] Bug#588125: Rubygems 1.3.7 broken with Ruby 1.9.2 in Debian -- help needed
jftucker at gmail.com
Fri Sep 10 17:41:09 EDT 2010
On 28 Aug 2010, at 03:56, Lucas Nussbaum wrote:
> While it's not the cleanest approach, it seems that it is the most
> reasonable solution given that upstream has failed to make sure that
> ruby1.9.2 wouldn't break with rubygems's rubygems. It might happen again
> in the future.
This solution makes me uncomfortable, however, I am entirely sympathetic. I think it is incorrect that we have multiple versions of RubyGems around with the same version tag. The issues of gem_prelude and ruby-core patches should be forwarded on to Evan Pheonix and ruby-core respectively, as they're out of our (or some of our) direct control.
> We need to decide on the following questions:
> - Do we want to make the installation of rubygems optional with 1.9.1?
> (as a separate package ?) That would probably be the right thing to do
> since I think that we should make the use of external package managers
> optional in Debian, but frankly, if we do that, some users are going
> to complain, and I'm totally tired of hearing complains about ruby
> packaging in Debian.
This is a hard choice for you guys I know, all I might ask is that you try to avoid too bigger patches, I will do what I can to help accommodate where appropriate.
> - Do we want to disable gem update --system? I think that we should
> allow a way for the user to do it anyway. For example, we could add a
> check for a "I_KNOW_WHAT_IM_DOING_ABOUT_GEM_UPDATE_SYSTEM" environment
> variable (ok, name could be improved). We would still refuse to gem
> update --system by default, but would accept it of the environment
> variable was set.
Also a hard problem, I want to try and make this easier, but I am still trying to find the best way to integrate such features between RubyGems and packagers. A hook in the operating system defaults to allow you to override this more cleanly is the only immediate solution that comes to mind. Related to the FHS discussion, I also wonder if it's outside of allowed policy for you guys to have a sort of "shim package" that just delivers a local install without recording all of it as a package, such that users can use it "as they expect", and an alternate "managed package", that would disable features such as this. Just a thought.
> - Paths: until consensus emerge in #448639, we should continue to
> install gems in /var. Those changes should be moved to
> rubygems/defaults/operating_system.rb, but we may do that later, and
> just continue with 01_default_gem_path.diff for now.
It would be preferred that it's done in the defaults file. We have of course, discussed some of this already, off the list. I thank you for your patience.
More information about the Rubygems-developers