Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
Lucas Nussbaum dijo [Mon, Jan 17, 2011 at 08:25:33AM +0100]:
> 5) Something I forgot to add is "dependencies on ruby interpreters".
> With gem2deb, we will get a single ruby-foo package that is supposed to
> work with all Ruby implementations (ruby1.8, ruby1.9.1, jruby,
> rubinius).
>
> I think that this ruby-foo package should depend on a "ruby-interpreter"
> virtual package, so that all users can install the ruby interpreter of
> their choice.
> And that each ruby interpreter should provide "ruby-interpreter".
> Additionally, we should move to using alternatives to select the ruby
> implementation. After that:
> - applications willing to force the use of ruby1.8 should use
> /usr/bin/ruby1.8 in shebang
> - applications willing to use the selected ruby implementation (whatever
> it is) should use /usr/bin/ruby
How is the compatibility between implementations right now? If a
package works across interpreters (it should be human-tested! Maybe
running its test suite with the different available interpreters would
do, although I don't want to do it for every uploaded package...), it
can depend on ruby-interpreter. If it breaks, say, under jruby, it
could depend on ruby-traditional | rubinius. It would be a win and
would as you said, encourage advance and homogeneization of the
implementations.
> The default ruby version should still be 1.8 at least for some time,
> given that most libraries are not supporting 1.9 yet.
Hmm... given that we would probably target now+2yr for Wheezy, and
given that Ruby devs are already talking about 1.9 as the stable
branch (with 1.8 as the maintenance branch), maybe we should think
about moving to default 1.9. Packages would still be built for 1.8,
but this would encourage us to push any incompatibilities to be fixed
(at or in colaboration with the upstream authors).
In my case -and again, this speaks of sloppy maintainership- I have
several libraries built for 1.8 and not 1.9 because it was not
supported when I first prepared the packages... But that are possibly
compatible today. And if they are not, maybe we should start bugging
the authors.
Reply to: