On Tuesday 19 August 2008 19:56, Mathias Gug wrote: > On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote: > > >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote: ... > > >> >Neil's proposal is to improve the gem command (from the libgems-ruby > > >> >package) so that binaries are installed in /usr/local/bin (thus > > >> > they're on the default path). If you'd use install gems from the > > >> > upstream source, binaries would be installed in /usr/bin/. The goal > > >> > is that gems installed by the gem command don't interfere with ruby > > >> > libraries and binaries installed by debian packages. > > >> > > >> Do you mean NOT on the default path then? > > > > > >No. The binaries included in the gem are installed in /usr/local/bin/, > > >which is on the default PATH. > > > > Doesn't that mean they'll get used in place of installed system packages? > > See my comment below. > > > >> >Upstream provided the necessary hooks to do so and Neil used the > > >> >update-alternatives system to handle multiple version of gems being > > >> >installed in /usr/local/bin/ rather than /usr/bin/. > > >> > > >> It does sound like progress. As long as we aren't actually packaing > > >> the gems themselves it seems like a reasonable way to go until Ruby > > >> Gems > > > > grows > > > > >> enough features to support proper integration of gems into the distro > > >> package space. > > > > > >Exactly. Neil's proposal is *not* aimed at integrating gems with the > > >distro package space but rather improve gem installation from source so > > >that it doesn't conflict with distro packages. Proper integration is a > > >long-term goal and we're looking at the Intrepid timeframe. > > > > > >The current rubygem package provides a gem command that installs gem > > >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH. > > >Neil's proposal uses update-alternative to make these binaries available > > >in /usr/loca/bin/ so that they're located in the default PATH. End > > >users won't have to modify their environment and gems will work OOTB. > > > > I can see how this doesn't conflict from an installation perspective, but > > unless I misremember where that is in the path, it will be used in place > > of anything provided through the distro. Am I missing something? > > Nope - you're right. Binaries installed by the gem command will be used > in place of binaries provided by packages since /usr/local/bin comes > first on the PATH. > > I assume that users installing gems from source (ie with the gem > command) want to use the upstream version of the gem rather than the one > provided by the distro. Using the gem command to install from source can > be viewed as a local customization of the system by the system > administrator - thus the usage of /usr/local/bin/.
For a legalistic reading of policy, I think there is nothing wrong with that, but how is a typical user of a gem going to know that if they install gem X a library used by gem Y, Z, and package A will be replaced/overridden? As a practical matter I think this declares it all to be the sysadmin's problem without giving them a way to know what risk they are taking or how to manage it. As I said in an earlier message in the thread it seems very like Windows DLL hell. Hopefully it will mature. I doubt that as a distro we can do much to improve this where it is now. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu