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