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

[Loïc Minier]

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


 So I don't know whether it would be hard to implement a
 /etc/environment.d which would be guaranteed to be used in all cases
 where /etc/environment is used, or whether it would be too dangerous to
 update PATH in /etc/environment -- there are certainly implementation
 questions -- but I don't think this should go against policy.

> This is related to section 9.9 of the Debian Policy [3], Environment variables:
>   A program must not depend on environment variables to get reasonable
>   defaults. (That's because these environment variables would have to be
>   set in a system-wide configuration file like /etc/profile, which is not
>   supported by all shells.) 

 Is there any shell which doesn't honor the PATH in /etc/environment?
 If yes, I think it's a bug; if not, we can build on the PATH set in
 this file IMO.

 And even if there were such shells, these shells would simply miss
 gems; the programs installed by packages would still work correctly,
 even commands to add / remove gems.  What might not work are gems
 themselves.

-- 
Loïc Minier