motu-release will revert libgems-ruby to the old state.
mathiaz at ubuntu.com
Thu Sep 4 05:08:19 BST 2008
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  by
> > using /etc/profile.d/. However it was rejected on the following grounds
> > 
> 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
> * 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  - the default PATH for apache2 is: /usr/local/bin:/usr/bin:/bin.
It seems to me that symlinking gems binaries to /usr/local/bin/ is the
simplest solution to cover both use case A. and B.
Ubuntu Developer http://www.ubuntu.com
More information about the ubuntu-devel