On 03/06/13 18:13, Brian K. White wrote:
On 6/3/2013 11:30 AM, Josef Reidinger wrote:
Well, not exactly. If yast depends on ruby, then the user is not free to
install the ruby of their choice, ie upgrades, source install, security
addons, performance/caching add-ons. They would either have to lock
their version of ruby to whatever yast needs, or maintain 2 ruby
installs one just for yast (and hope yast can even be told to use it),
or risk breaking yast. Systems run a lot longer than suse supports them.
So after a very few months, suse is no longer updating yast on that
version of suse, but the user is still using the system and probably
wants to update ruby.
This is a problem with the packaging and also with the gem concept
upstream. In theory, nothing should prevent various interpreters to be
installed (like we do with Java).
Only C extensions using the MRI should be kept separate, as even if the
MRI apis across them are source compatible, I don't think they are ABI
But nothing should prevent interpreters to share the gems targeted to a
specific version of Ruby as a language (like we do with /usr/share/java
more or less).
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org