motu-release will revert libgems-ruby to the old state.
Loïc Minier
loic.minier at ubuntu.com
Mon Sep 1 20:43:19 BST 2008
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
More information about the ubuntu-devel
mailing list