[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Candidate new Ruby policy



On Tue, Apr 7, 2009 at 12:14 AM, Lucas Nussbaum
<lucas@lucas-nussbaum.net> wrote:
>> 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.

What about native libs? Do they have to have Java replacement for their
C code? (Of my packages, only Redcloth has that.) Or is there a way to
build and link .so libraries agaist JRuby?

> 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

True.

>> 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.

Fair enough.

> 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.

Ok, then that's the second reason for sourceful uploads: to make
migrated packages stand out more by renaming them. Although, for
argument's sake, there might be less radical ways of tracking migrated
packages (e.g. Depends: ruby-support (>= 1.0)).

>> 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? :-)

That's enough for a sourceful upload of _a_ package, but not necessarily
for a burn-all-bridges no-backwards-compatibility mass upload of _all_
Ruby packages.

>> 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

Not if we use /usr/lib/ruby/vendor_ruby which is already supported by
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.

I tried to address this concern below.

>> 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?"

What I'm trying to figure out is a way to reduce the amount of work for
everyone involved, not to increase it. Migration will require
non-trivial changes to over 200 packages. Mass migration means that we
can't wait for all maintainers to update the packages and that someone
has to do a lot of NMUs, to reduce the time when Ruby in Debian will be
broken.

Unless ruby-support auto-magically detects API compatibility with all
supported Ruby interpreters, the work of testing packages against
interpreters is not going anywere and still needs to be done, regardless
of the approach we take.

If we do symlink farms, the packages that will turn out to have API
problems will not install the symlinks for incompatible interpreters.

- Pro: users who attempt to use the library with a wrong interpreter
  will immediately get LoadError.

- Contra: we have to detect API compatibility upfront (for 200 packages)
  and change the packaging every time compatibility status changes;
  users who want to fix and test API problems in the library have to do
  their own packaging first, or resort to non-Debian means of installing
  the library.

If we do single vendor_ruby in $LOAD_PATH of all interpreters, the
pure-ruby libraries with API problems will still be available for
incompatible interpreters.

- Pro: we only have to fix the packages which are actually broken, we
  don't have to change anything if API issues are fixed upstream, users
  can try out the library with all interpreters out of the box and
  report and/or fix the API issues if they want.

- Contra: API compatibility status is not reflected explicitly by the
  package, users who attempt to use the library with a wrong interpreter
  will get (potentially weird and/or intermittent) problems at run time.

The latter sounds pretty bad, but in reality it's quite manageable.

First of all, we already have a known-good interpreter that is
compatible with all our Ruby library packages, and, by no coincidence,
this interpreter is the default Ruby interpreter installed when you
apt-get install ruby. I mean, of course, ruby1.8. This means that people
who just need a piece of software that happens to be written in Ruby,
and who don't want to know anything about different Ruby interpreters
and API compatiblity issues, will not install non-default interpreters
and will not get those scary weird intermittent API-induced bugs.

Users who do care about alternative interpreters are much more likely to
read the interpreter's README.Debian, where we can warn about possible
API compatibility issues, instruct how and where to report these issues
(raise a normal bug against a specific library package), and point to
interpreter's documentation which hopefully explains what are the
typical exceptions and how they should be addressed. We can even rub
this in via a debconf screen.

At some point we will want to upgrade ruby-default from ruby1.8 to
ruby1.9.x, and that will be the earliest point when we will really need
that API compatibility data. By that time, most of the libraries should
already be fixed upstream, and even if we still need to do mass API
compatibility tests, the number of packages to be tested will be greatly
reduced by excluding the packages which are explicitly documented to be
compatible with Ruby 1.9.x (in changelog entries or bugs in Debian BTS
or both). Not to mention that such tests wouldn't need any changes to
the packages whatsoever.

-- 
Dmitry Borodaenko


Reply to: