Possible solutions to improve rubygems for intrepid

[Stephan Hermann]

Hi Kees,


On Tue, 2008-09-16 at 09:17 -0700, Kees Cook wrote:
> Hi,
> 
> On Tue, Sep 16, 2008 at 03:19:29PM +0200, Stephan Hermann wrote:
> > On Tue, 2008-09-16 at 09:42 +0200, Lucas Nussbaum wrote:
> > > On 15/09/08 at 21:51 -0400, Mathias Gug wrote:
> > > > Hi,
> > > > 
> > > > Here is a summary of the different solutions that have been discussed to
> > > > fix bug 145267 [1] aka binaries installed by gems via the gem command
> > > > are not on the PATH:
> > > > 
> > > > 1. Provide binaries in /usr/local/bin: 
> > > > 
> > > >   a. Via symlinks from /var/lib/gems/1.X/bin/: uses postinst hooks and
> > > >   update-alternatives. This is what the reverted upload implemented [2].  
> > > > 
> > > >   b. Put binaries directly in /usr/local/bin instead of
> > > >   /var/lib/gems/1.X/bin/. This solution has been suggested by Lucas [3].
> > > > 
> > > > Issues:
> > > > 
> > > >   * installed binaries could be overwritten by other installation
> > > >     systems and breaking binaries installed by the gem command. The gem
> > > >     sub-system would be less robust due to its links in /usr/local/bin/.
> > > 
> > > This is not different than manually installed software (using
> > > ./configure ; make ; make install), so it's unlikely to be a surprise
> > > for the user.
> > > 
> > > Note that 1.a requires upgrading rubygems to a VCS snapshot (so hooks
> > > can be used), while 1.b is a one-liner away.
> > 
> > Both ideas have one problem:
> 
> I have to disagree.  As Lucas says, this is identical to having an admin
> download and use the gems directly. 

Yes...but admin means: "Manual intervention and someone who knows what
he does".
John Doe doesn't know normally what he does...that's my experience with
RoR devs who are using gems and RoR in general.

> 
> > User 1 just does "gem install ..." and somehow all the stuff lands
> > somewhere in the general $PATH (/usr/local/bin/ or via alternatives).
> 
> This is _expected_.  Without this, the software isn't actually useful in
> any real sense of the word.  If the software gets hidden, the User will
> ignore the Ubuntu-installed version of gems, and install it from 3rd
> party source, and end up with things directly installed anyway.

TBH, gems who are delivering any binaries are not useful. but that's
just me. 
For what do I need gems?

i.e. activerecord...a very popular gem for RoR devs.
Well, most RoR Devs are using anyways the latest release of this
package, which means it won't be in a distro anyways.
But, on the other hand, it's nothing more then like a PEAR lib is today.
It's just a bunch of code, which is really a library...so, what's the
problem to package it nicely?

Yes...the RoR dev...who needs the most bleeding edge...but then he/she
is on it's own....so we can give them any help to not mess his/her
system with cruft, but telling him: "ok, you downloaded now software
which doesn't belong to ubuntu, you are on your own and you find it <put
your path != $PATH or alternatives here>".



> 
> > User 1 just runs something from real ubuntu packages and this software
> > fails, because of different versions of dependend software
> > in /usr/local/bin or specified in alternatives.
> > User 1 just runs something from real ubuntu packages and this software
> > fails, because of different lib versions of dependend software.
> 
> This would happen with 3rd party source too.  It is not something that
> is solvable outside of dpkg packaging.  We should help people in the
> least destructive way, which is using the /usr/local symlinks.

Right. But "gem install <foobar>" is different from "wget
foobar.tar.gz ; tar -xzf foobar.tar.gz ; cd foobar-0.x; ./configure ->
output: "It seems you don't have library <veryimportantlib-99.5>
installed, please do..."

gem is a package manager, dpkg is a package manager...
I wonder when the time comes, that people are asking for making "rpm" on
debian usable, because it could be, that ISV X do provide RPMs for RPM
Distro Y, but it's also valuable and usable for Ubuntu...

I wonder what discussion we have then? Makeing RPM able to relocate
non-relocatable rpm packages to push the binary stuff into /usr/local/*
because it's just what "./configure ; make ; make install" does?


> 
> > User 1 writes bug reports to Launchpad, because he/she thinks it's
> > ubuntus problem, but in reallife it's a gem package which disturbed
> > his/her system.
> 
> This again will happen anyway when they have 3rd party source installed.
> However, it's _harder_ to diagnose when they're not using the Ubuntu
> gems installer since we will not be able to get versions on things like
> the installer, lists of symlinks, etc.  Non-dpkg software installs are
> always getting in the way of LP bug reports; this is not anything new to
> triagers.

Right...but let's go back to my example,with activerecord..

Take php-db, which is, comparing gem and pear, similar.
People will use pear, for sure, but they can use packaged pear stuff
more easily...if they have it.

Question: Why can't we package the most common ruby stuff nicely, and
providing a stable overlay archive for updated versions for stable
ubuntu releases? (signed ppas? :)))


It would make the life of admins more easy and enjoyable..
Many devs (php, perl, ruby, python) will still using third party sources
(not packages) from upstream, but they are already on their own.

> 
> > Having the gem installation path somewhere far away from the standard
> > PATHs (speak: $PATH) is a better approach and the responsible admin or
> > the developer can symlink, move it, copy it somewhere where it fits for
> > his/her system.
> 
> That's fine for them if they choose to use 3rd party source.  For what
> ships with Ubuntu, we should help the default choice: making the gem
> useful immediately while doing the best we can to maintaining system
> sanity.

Would you underline that for my RPM example? :) Regarding gem and rpm,
this is the same...
For pear, I never saw pear installing some binaries...and I know there
are some php pear libs which are in need of other binary libs (libssh2
e.g.)

I'm ok with any decision, until it wouldn't clutter a stable live
system...I wonder what hold us back to package the ruby libs nicely for
debian/ubuntu?


Regards,

\sh

-- 
Stephan '\sh' Hermann           | OSS Developer & Systemadministrator
JID: sh at linux-server.org        | http://www.sourcecode.de/
GPG ID: 0xC098EFA8              | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8