Possible solutions to improve rubygems for intrepid

Scott Kitterman ubuntu at kitterman.com
Tue Sep 16 18:31:17 BST 2008


On Tuesday 16 September 2008 12:17, 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.

I generally agree with the idea that /usr/local belongs to the admin and what 
the admin chooses to install there is their business and not ours.  The 
problem I have is that if the admin chooses to install Gem A, he can also get 
B, C, D and an embedded copy of some system library.  That's where my concern 
kicks in.

If Gem A in (or symlinked) in /usr/local and in the system path, but the stuff 
it drags in in not in the system patch, just somewhere where Gem A can find 
and use it, then I think the integrity of the system is reasonably preserved 
(if A is crack, there's nothing we can do, we just need to not break other 
stuff).

Scott K



More information about the ubuntu-devel mailing list