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 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
