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

Stephan Hermann sh at
Thu Sep 4 07:05:36 BST 2008


On Thu, 2008-09-04 at 00:08 -0400, Mathias Gug wrote:
> Hi Loïc,
> On Mon, Sep 01, 2008 at 09:43:19PM +0200, Loïc Minier wrote:
> > On Mon, Sep 01, 2008, Mathias Gug wrote:
> > > This was indeed suggested at the very beginning of the bug thread [1] by
> > > using /etc/profile.d/. However it was rejected on the following grounds
> > > [2]
> > 
> >  I'm not quite sure I agree with the rationale; I agree it's a good
> >  policy that programs /installed by packages/ must not depend on
> >  environment variables to get reasonable /defaults/.  However:
> >  * it's not against policy that programs installed via gems (not
> >    installed by packages) rely on a specific PATH or LD_LIBRARY_PATH to
> >    work
> >  * it's not against policy to setup a system to try to expand its PATH
> >    to use additional data, as long as using the default PATH wouldn't
> >    break the system and its packages
> What do you mean by "as long as using the default PATH wouldn't break the system and its packages" ?
> Do you mean that only the gem system should be setup to use gem
> installed binaries ?
> >  * the rubygems package doesn't require a custom PATH setting to do its
> >    work (installing gems) -- however you do need special settings to use
> >    the installed data (gems)
> We have two use cases to cover here:
>  A.The end user wants to use a binary provided by a gem from the command
>    line (shell environment). 
>    Example: the rails command to start a rails project. 

Rails is a webframework...rails is packaged (apt-get install rails)
need to use gem.

>  B. A daemon that runs gem installed binaries. 
>    Example: cgi scripts under apache2.

Well, it doesn't need $PATH, it just needs some simple, magically known
by apache admins, configuration.

I don't think ruby-gem cgis are different from any other. So
installation of cgi binaries can be anywhere, when you know how to
configure your apache correctly.

> >  * Ubuntu went through the hassle of promising that PATH is set in
> >    exactly one place across the whole system
> >    <>; especially in light of "Ubuntu
> >    wants to remove /usr/games from the default $PATH" in the above spec,
> >    it seems that it's a long term desired distro feature to define the
> >    PATH in a central place for various use cases and this sounds like a
> >    good use case
> > 
> >  An issue I see with relying on the PATH env var is that its old value
> >  is in a bunch of running processes; probably not worse than upgrading a
> >  lib such as libssl and having to restart services to pick it up.
> >
> This seems to cover use case A, but not use case B as pointed out by
> Kees [1] - the default PATH for apache2 is: /usr/local/bin:/usr/bin:/bin.
> [1]:
> It seems to me that symlinking gems binaries to /usr/local/bin/ is the
> simplest solution to cover both use case A. and B.

You can obviously also set your PATH to the /var/lib/gems/*/bin location
manually, which is a very sane way to do this, so sysadmin knows, that
there could be some trouble later on.

What you didn't list is, that most RoR developers do want the latest and
greatest gems installed...if you really need this, you should be on your
own, because you obviously know what you are doing.


Stephan '\sh' Hermann           | OSS Developer & Systemadministrator
JID: sh at        |
GPG ID: 0xC098EFA8              |
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

More information about the ubuntu-devel mailing list