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

[Adam Jacob]

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.

> 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.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam at opscode.com