[Rubygems-developers] Bug#588125: Rubygems 1.3.7 broken with Ruby 1.9.2 in Debian -- help needed

James Tucker 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 mailing list