On Mon, Apr 6, 2009 at 8:22 AM, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote: >> > [A] Ruby libraries must support as many as possible of the Ruby versions >> > available in Debian. That currently includes Ruby 1.8, Ruby 1.9.0 >> > (soon 1.9.1), JRuby 1.0, and JRuby 1.1. (Should we drop JRuby 1.0?) >> > ruby-support --supported lists the versions that should be >> > supported.
How do I add JRuby support to my packages? $ grep-aptavail -sPackage -FDepends jruby|wc -l 0 I think something along the lines of the hello package, but following all the requirements and recommendations of the new Ruby policy, would help people figure out how to migrate. Also, is there any reason that Rubinius and Cardinal are not in Debian, or is it just because noone is interested in trying them out? >> > [C] Ruby library package naming policy. Ruby library packages can >> > choose between two naming schemes: >> >> This scheme appears to be a significant departure from current common >> practice: > [...] >> Now, if you really do intend that the naming scheme for roughly all >> currently extant Ruby libraries be changed, you might want to discuss the >> impact of that change with ftpmasters, and I'd *definitely* expect to see a >> *very* strong rationale for why the current naming scheme is unworkable and >> *needs* to be changed. > > For pure-ruby libraries, we need to move away from manually providing > support for all ruby versions. It is not manageable to do sourceful > uploads of all libraries each time a new major ruby version is released. > That's what ruby-support provides. > > But this new policy will require sourceful uploads of all library > packages, with a change in the number of binary packages (so we would > have to go through NEW anyway), so it is a good idea to pass as many > large-scale changes as possible at the same time. Like several others, > I'm not a huge fan of the libxxx-rubyxxx naming scheme, and moving to a > pythonish scheme, and away from a perlish one, seems logical since > ruby-support is just ruby's version of python-support. I think the number of sourceful uploads is not the only problem that may be caused by a massive renaming of Ruby library packages. What will be the impact on reverse dendencies of all the renamed libraries? Can we downgrade this naming change from requirement to recommendation, allowing but discouraging the old naming scheme? Is a single pure Ruby package for all Ruby versions the only reason for sourceful uploads of all Ruby library packages? Wouldn't a Ruby interpreter package that adds support for this policy also be backwards-compatible with packages following the old policy? This would allow to migrate packages one by one, instead of a painful mass-migration. Wait a second, why don't we use /usr/lib/ruby/vendor_ruby (which is already included in $LOAD_PATH for ruby1.8 and ruby1.9? We will have to patch vendor_ruby support into jruby anyway, so why don't we point it there as well, and mandate this in the policy? With this, we won't even need a symlink farm for pure-ruby libraries, all we need is to tell people to put their .rb files there. -- Dmitry Borodaenko -- To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
