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

[Loïc Minier]

On Thu, Sep 04, 2008, Mathias Gug wrote:
> >  * 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" ?

 I mean that even if the gems aren't in the PATH, the packages continue
 to work.

> Do you mean that only the gem system should be setup to use gem
> installed binaries ?

 No, I mean that it's not a policy violation to try to add the gem
 binary path to PATH on a best effort basis because packages will
 continue to work whether PATH has the gem binary patch or not.

 I wish manually installed gems benefit the users of the system
 (including the admin) and services as much as possible since someone
 went through the hassle of installing the gems: it means they either
 additional software or newer software available as gems.

>  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. 

 Let's stop mentionning this one which is well understood and covered by
 all proposals so far.

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

 That one I'm afraid I thought would be covered by /etc/environment, but
 I now realized it's not.

 I thought /etc/environment was also sourced by central sysvinit scripts
 to affect all child processes, but this is wrong, it is only sourced by
 some scripts and used by pam_env for some services.

 I should dig up the rationale for implementing support of
 /etc/environment in the way; the OneTruePath spec doesn't hint at this.


 I'm certainly again overly naive, but it would seem to me that a
 central definition of the default environment should cover more than
 pam sessions and a handful of init scripts.
   Shall we revisit OneTruePath to cover non user-session use cases?  I
 certainly understand that pam_env made it easy to implement OneTruePath
 for cases where the environment needs to be cleared/sanitized (sshd
 comes to mind), but it seems to fall short on covering the use case you
 describe as B.
   Perhaps we can simply enforce this support in init/upstart?


 However, if there are reasons that we didn't want to support setting
 the PATH for *everything* which drove the current implementation of
 OneTruePath to only use pam_env and selectively read /etc/environment
 from some key places (e.g. gdm, cron) then these reasons probably apply
 equally to gems.
   In this case, we should pursue with the current style and add support
 for /etc/environment in apache2.

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

 While it might be simple to build on the current level of support for
 the /usr/local/bin path in various places, it seems to be a dangerous
 solution, even more when using the alternatives system.

 I think some admins run things like ./configure (the default usually
 installs in /usr/local) && make & sudo make install to install random
 software.  This would clash with the current symlinks.
   Ubuntu systems also need to allow similar situations to other
 parallel distribution/packaging systems (as provided by python tools,
 perl tools etc.).

-- 
Loïc Minier