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