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

[Lucas Nussbaum]

On 30/08/10 at 13:58 -0400, Tim Olsen wrote:
> 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.

I think that the best way to solve that problem is to follow what the
upstream developers are doing. After all, if we decide to diverge, and
somehow get it wrong, we will be blamed (and we know from the past that
the Ruby community is quite good at blaming people). If upstream makes
suboptimal choices, and we follow them, we can transfer the blame to
them :P

Lucas