Re: Candidate new Ruby policy
On 06/04/09 at 19:56 +0300, Dmitry Borodaenko wrote:
> 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?
Currently, you would have to also install the files into jruby's load
path, preferably in a different binary package.
> $ grep-aptavail -sPackage -FDepends jruby|wc -l
> 0
Yeah, that's the problem.
> 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.
Sure. But first, we have two agree on which goals we want to reach.
> 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?
Apparently noone is interested. Once ruby-support is in Debian and
working, it should be easy to automatically add rubinius support to
packages, though.
> >> > [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?
90% of the reverse dependencies will probably also require changes,
because they are also ruby packages. I don't think that there are that
many packages that:
(A) depend on ruby libraries
(B) are not ruby libraries themselves
> Can we downgrade this naming change from requirement to
> recommendation, allowing but discouraging the old naming scheme?
No. Either we rename all packages, or we rename none of them. Having two
different naming schemes for Ruby packages will be a nightmare. If we
really really want to minimize the number of changed packages, we could
keep the current libxxx-rubyxxx scheme, and have:
- libxxx-ruby for pure-ruby libs
- libxxx-ruby, libxxx-ruby1.8, libxxx-ruby1.9, etc. for native libs.
However, if we do that, it will be much harder to track which packages
have been migrated or not.
> Is a single pure Ruby package for all Ruby versions the only reason for
> sourceful uploads of all Ruby library packages?
Well, isn't that enough? :-)
> Wouldn't a Ruby
> interpreter package that adds support for this policy also be
> backwards-compatible with packages following the old policy?
What we could do is install all pure-ruby libs in /usr/lib/debian-ruby
(or whatever), and add /usr/lib/debian-ruby to the load path of all
interpreter packages.
However, if we do that:
(A) we completely diverge from upstream
(B) we won't be able to deal with packages that are not supported by a
specific ruby version, or that require changes between ruby versions
I really don't want to go towards that path.
> 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.
That's what I just said. That means ignoring all API problems. We would
have to patch Ruby libraries so that they work with all Ruby versions at
the same time. (possibly testing the running ruby version so that we
know which version of the code to use)
How much time would you be willing to invest on this? Basically, all of
this boils down to "who wants to do the (boring) work?"
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: