motu-release will revert libgems-ruby to the old state.

[Lucas Nussbaum]

On 04/09/08 at 23:57 -0400, Scott Kitterman wrote:
> On Thursday 04 September 2008 21:13, Dustin Kirkland wrote:
> > On Thu, Sep 4, 2008 at 7:46 PM, Mathias Gug <mathiaz at ubuntu.com> wrote:
> > > On Thu, Sep 04, 2008 at 04:04:57PM +0200, Loïc Minier wrote:
> > >>  No, I mean that it's not a policy violation to try to add the gem
> > >>  binary path to PATH on a best effort basis because packages will
> > >>  continue to work whether PATH has the gem binary patch or not.
> > >>
> > >>  I wish manually installed gems benefit the users of the system
> > >>  (including the admin) and services as much as possible since someone
> > >>  went through the hassle of installing the gems: it means they either
> > >>  additional software or newer software available as gems.
> > >
> > > I assume you meant "it means they *want* either additional software or
> > > newer software available as gems".
> > >
> > > Could the following statement be considered a corollary of the above ?
> > >
> > >  Binaries installed by the administrator should take precedence over
> > >  binaries provided by packages.
> > >
> > > That's my interpretation of the following line in /etc/environment:
> > >
> > > PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/g
> > >ames"
> >
> > My reading of the FHS on /usr/local/bin corroborates that.
> >  * http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
> >   * "The /usr/local hierarchy is for use by the system administrator
> > when installing software locally."
> >
> > If an administrator wanted to install something above and beyond the
> > normal Ubuntu packages, that would be his/her prerogative, and s/he
> > should do that in /usr/local/bin.  This could certainly happen as any
> > given untar/make/make-install (perhaps using --prefix), for
> > self-written software, or as-yet unpackaged software for Ubuntu.
> 
> Personally, in the case of Gems, I think it's not problematic for a Gem that 
> an admin has specifically installed to go in /usr/local for exactly these 
> reasons.  Where I think the disagreement stems from is how to characterize 
> the additional program that Gems will pull in with them.  I do not believe it 
> is correct to characterize these as 'installed by the adminstrator'.  They 
> were installed by the Gems system and should not be in the default path.

I disagree. The easiest way to see rubygems is to see it as "tar on
steroids". If you consider it differently, then you open the door to
hacks to try to integrate gems with apt. Since nobody seem to want that
on the rubygems side, this is likely to fail or stay in an half-broken
state, and make everybody unhappy. (rubygems users, and Ubuntu
maintainers that will have to deal with the bad press)

For the same reason, I don't think that we should package gems, because
that would be about the same as packaging tarballls. The only sane way
to do that would be to have empty packages that do "gem install foo" in
postinst.

It's a shame that a big part of the Ruby community doesn't acknowledge
that other packaging systems exist. But working around that social
problem using technical hacks is not going to lead anywhere.
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |