Re: Candidate new Ruby policy
On 08/04/09 at 19:40 +0300, Dmitry Borodaenko wrote:
> 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.
That's a rather fair summary of the problem, but your are missing one
half of the issue.
1) there are libraries which aren't compatible with Ruby1.9 yet. That's
addressed by your summary.
2) there are libraries which are no longer compatible with Ruby1.8,
because they use new features in Ruby1.9. Such libraries might become
more and more common. And even if Ruby1.9 becomes the default Ruby
version in Debian, we might want to keep Ruby1.8 around for some time.
I don't really like the perspective of having no simple way to exclude a
library from being loaded with a given version of Ruby.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: