> > > Putting the original executable in /etc/alternatives is not a good idea. > The script you put in /usr/bin may get overwritten at some point, with > a security update, but still be at version 1.8, so you'd end up without > your wrapper, at least, and perhaps still running the binary you moved, > without the fix. > > I'd also ask, which I forgot in my first response to your question, is > this something that needs to be done for all users on your system or is > it a personal script? > > I think the Debian policy in this case would guide you only if what > you're doing is for all users of the system. If you're doing this for > yourself, most UNIX/Linux users I know would create an alias or function > to do it, in their own work space (~/bin, ~/.aliases, etc). >
Looks like I have more than one issue. I'd like to get this issue of the best way to create and locate the wrapper script out of the way first. >From you are saying, I guess I would leave the /usr/bin/ruby1.8 alone, as installed. Then, in order to make sure that the environment variable I want set get's set every time ANYONE in the system invokes ruby, I'd make a wrapper script and place it where? In /usr/local/bin ? This seems like a great idea. I was only referring to debian policy's recommendations on how to handle the application specific environment variable with a wrapper script, not the location of the wrapper script, about which I read nothing in the policy manual. Perhaps because anyone with experience would know where to put it. Anyhow, does this scenario seem like a good idea, as far a the location of the wrapper script goes, considering i want the env variable set for all users invoking ruby?
