On 08/30/2010 01:38 PM, Adam Jacob wrote: > Tim Olsen wrote: > >> I am a developer and being able to switch between Ruby 1.8 and Ruby >> 1.9.1 gems is important for me. For example, I use Rubygems-installed >> rake to run my automated tests. All I have to do to see if my tests >> work on a different version of Ruby is to update my PATH. Making sure >> that a Ruby library works for both Ruby 1.8 and 1.9 is an important >> activity for a Ruby library developer nowadays. >> >> One minor point: you do not need to be root to modify /usr/local. On >> default Debian installs (but not in Ubuntu), you only need to be in the >> staff group. > > While this is indeed convenient for the use case, I would argue it's > totally out of whack with the expectations that anyone coming to > Debian from the Ruby community expects. The majority of people > installing rubygems are doing so because they are using the gem - not > because they are doing a development cycle. The development use case > has many other options (rvm, for one) that solve the problem - the > end-user case does not, as only Debian policy can fix it. So, I feel > your pain, but there is a greatest good argument here in favor of > /usr/local.
Ok. I agree with you here now. I'll just have switch to using rvm or the like. > >> Besides, I'm not convinced that using /usr/local is itself >> FHS-compliant. (I've sent an email earlier about this but I haven't >> seen it go through yet). If upgrading the rubygems package may modify >> /usr/local then that violates the FHS: "It needs to be safe from being >> overwritten when the system software is updated." > > Upgrading rubygems by itself would not update /usr/local, as it is > packaged directly within Debian - so it's entirely within our control > as to whether or not it updates anything in /usr/local. To my > knowledge, there has never been a rubygems upgrade that forces an > update of installed gems automatically, which would be the only case > in which this might be in jeopardy. What I was more thinking of was if there was a change in how rubygems organizes things under /usr/local. Lucas proposed storing gems under /usr/local/lib/ruby/gems/1.8. But if rubygems needs to move things around upon an upgrade, then that's technically a violation. Even setting up directories under /usr/local upon rubygems installation might be considered a violation. One possibility is to store everything *but* executables outside of /usr/local. Tim > > Adam > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
