On Sun, 11 Mar 2012 11:16:20 +0100
Stephan Kulow <coolo(a)suse.de> wrote:
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
4. even more complex stuff :)
Well, it looks like deja-vu. I see similar discussion for python3. Well I think that we
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
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
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org