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

Mathias Gug mathiaz at ubuntu.com
Thu Sep 4 05:08:19 BST 2008


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. 

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

>  * Ubuntu went through the hassle of promising that PATH is set in
>    exactly one place across the whole system
>    <https://wiki.ubuntu.com/OneTruePath>; 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]: https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026338.html

It seems to me that symlinking gems binaries to /usr/local/bin/ is the
simplest solution to cover both use case A. and B.

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com



More information about the Ubuntu-motu mailing list