| 1 |
On 01/15/2012 05:24 PM, Hilco Wijbenga wrote: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> The dev-ruby/rubygems ebuild adds "-rauto_gem" to the global RUBYOPT. |
| 5 |
> This breaks my own scripts so I have removed it from /etc/env.d. So |
| 6 |
> far, so good. |
| 7 |
> |
| 8 |
> I just tried upgrading dev-ruby/json and it failed because I did not |
| 9 |
> have RUBYOPT set. Obviously, the "fix" was easy but now I'm wondering |
| 10 |
> ... is this really the best approach? |
| 11 |
> |
| 12 |
> It does not seem like a good idea that the rubygems ebuild sets |
| 13 |
> RUBYOPT and subsequent (Ruby Gems related) emerges break without it. |
| 14 |
> Would it not be simpler and more reliable if ebuilds that need it |
| 15 |
> simply execute "export RUBYOPT=..." prior to running? Why does it have |
| 16 |
> to be in the global environment, forcing it on every user? |
| 17 |
> |
| 18 |
> If there is a requirement for this to be in the global environment, |
| 19 |
> what is the consequence of unsetting RUBYOPT in my own .bashrc (or |
| 20 |
> similar)? Is that "safe"? Or does that break something that I simply |
| 21 |
> haven't noticed yet? |
| 22 |
> |
| 23 |
|
| 24 |
(1) I don't know much about ruby packaging |
| 25 |
|
| 26 |
(2) Keeping (1) in mind, I agree with you |
| 27 |
|
| 28 |
(3) You're asking the wrong people |
| 29 |
|
| 30 |
Try asking on the -dev list, or filing a bug. They'll just close it if |
| 31 |
it's considered invalid. |
| 32 |
|
| 33 |
This bit me once long ago: ruby scripts running from cron don't have |
| 34 |
their RUBYOPT set, so scripts that normally work "magically" fail. Since |
| 35 |
I never set RUBYOPT myself, I didn't expect it to be set. Of course, I |
| 36 |
just forgot to require rubygems in my script. |
Archives