motu-release will revert libgems-ruby to the old state.
loic.minier at ubuntu.com
Thu Sep 4 15:04:57 BST 2008
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
> 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.).
More information about the Ubuntu-motu