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. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
