[DRE-maint] Bug#448639: Debian Bugs information: detailed logs for Bug#448639

[Tim Olsen]

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
>