2008/5/24 Lucas Nussbaum <email address hidden>:
> Right. I'm waiting for your patch.
Ok. Lucas. I'm going to send a patch via Ubuntu. The patch will be to
include /var/lib/gems/xxx/bin in the system path within the rubygems
module. There are plenty of bugs here on Launchpad complaining about
that little 'oversight'. And I know it irritates the very devil out of
everybody using Ubuntu Ruby to get real things done. In fact the
standard approach is to do a 'gem update --system' after installation
to get back to the normal gem infrastructure.
If you can get your team to accept that within the Debian rubygems
package then we have a fighting chance of moving forward together.
If not then there may have to be some sort of fork.
> Sure. Try to talk to the gems developer about that. I'm sure they will
> listen to you. You might want to have a look at the ML archives first,
> though, it's not like we tried. But I'm not going to engage with another
> hateful discussion with the rubygems developers.
I don't find them that bad. But then I have a slightly more pragmatic
position with Rubygems and a very, very large itch that I need to
scratch.
I will talk to Eric, et al and see if we can come to some accommodation.
As to the substance of this bug, I can live with the splitting of the
Ruby1.9 system into the sub-packages if they are pulled back together
into a single point somehow. It would be much better if ruby1.8 and
ruby1.9 pulled them all back together again for the average user.
Would it not be more sensible to have a ruby1.8-core and ruby1.9-core
package to allow minimalist dependencies but incorporate gem1.8 and
gem1.9 (along with irb, ri, rdoc) in the ruby1.8/ruby1.9 packages and
target them at those developing with the language?
2008/5/24 Lucas Nussbaum <email address hidden>:
> Right. I'm waiting for your patch.
Ok. Lucas. I'm going to send a patch via Ubuntu. The patch will be to gems/xxx/ bin in the system path within the rubygems
include /var/lib/
module. There are plenty of bugs here on Launchpad complaining about
that little 'oversight'. And I know it irritates the very devil out of
everybody using Ubuntu Ruby to get real things done. In fact the
standard approach is to do a 'gem update --system' after installation
to get back to the normal gem infrastructure.
If you can get your team to accept that within the Debian rubygems
package then we have a fighting chance of moving forward together.
If not then there may have to be some sort of fork.
> Sure. Try to talk to the gems developer about that. I'm sure they will
> listen to you. You might want to have a look at the ML archives first,
> though, it's not like we tried. But I'm not going to engage with another
> hateful discussion with the rubygems developers.
I don't find them that bad. But then I have a slightly more pragmatic
position with Rubygems and a very, very large itch that I need to
scratch.
I will talk to Eric, et al and see if we can come to some accommodation.
As to the substance of this bug, I can live with the splitting of the
Ruby1.9 system into the sub-packages if they are pulled back together
into a single point somehow. It would be much better if ruby1.8 and
ruby1.9 pulled them all back together again for the average user.
Would it not be more sensible to have a ruby1.8-core and ruby1.9-core
package to allow minimalist dependencies but incorporate gem1.8 and
gem1.9 (along with irb, ri, rdoc) in the ruby1.8/ruby1.9 packages and
target them at those developing with the language?
Let me know what you think on that last point.
--
Neil Wilson