On Sun, 11 Mar 2012 11:16:20 +0100
Stephan Kulow
Hi,
As I have a high interest in getting ruby 1.9 (as default ruby) into factory to replace the soon out of maintenance 1.8, darix invited me to work out a plan how to have gems build for 1.8 and 1.9.
So I renamed ruby to ruby18 and added a ruby package that defines the default ruby. With this I rebuilt all gems that I have installed on my workstation as 1.9 version.
But that doesn't solve the 1.8 backward problem - and while it doesn't sound _soo_ important, I already found the lack of a way to test the 1.8 stack in comparision when porting quite bothering :)
So I changed the gem2rpm template to output always two ruby versions. ruby18-gem-gettext and ruby19-gem-gettext. This _kind_ of works, but both these gems install stuff in %_bindir and they conflict (other files are in ruby version specific dirs).
I see several options: 1. Most of the executables are just wrappers for the real stuff happening in ruby modules, so just package the executables for the default ruby version. 2. add a suffix to the non-default ruby versions 3. add a suffix to all executables and provide update-alternative hooks all around 4. even more complex stuff :)
Well, it looks like deja-vu. I see similar discussion for python3. Well I think that we can inspire. I think that we should use 1. as default as from binary you want to have it working ( I don't care if a use library liba or libb as long as it working ). With exception where it make sense ( e.g. generators of code which could be different for different versions ). Josef
The mid term goal is to have it clear from the binary rpm name which ruby version it is for - ruby 1.8 will be around for a while.
If you want to see my state, check http://s.kulow.org/4
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org