Re: Candidate new Ruby policy
On Mon, Apr 6, 2009 at 8:22 AM, Lucas Nussbaum <lucas@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
Reply to: