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 compatible. 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org