Fw: Re: Ruby 1.8 transition plan; debian-ruby
As rightfully pointed out by Fumitoshi UKAI, this discussion belongs to
the wider audience of debian-devel, especially since Ruby 1.8.0 was
released today.
NB: some points raised here can be of interest not only to Ruby
developers, but also to developers from other scripting languages.
Generic questions are:
Is there or shouldn't there be policy or guidelines on major version
transition for scripting languages?
What considerations should be taken into account when deciding whether
to keep several different major language versions co-installable?
Where should libraries written in a scripting language go? (That one is
my pet question: FHS seems to point to /usr/share/, while in Debian,
most languages use /usr/lib/, and I have arguments against both :)
Ruby-specific question is, of course, how do we deal with Ruby 1.8
transition?
--
Dmitry Borodaenko
----- Forwarded message from Fumitoshi UKAI <ukai@debian.or.jp> -----
Date: Thu, 24 Jul 2003 05:12:32 +0900
From: Fumitoshi UKAI <ukai@debian.or.jp>
To: Dmitry Borodaenko <d.borodaenko@sam-solutions.net>
Cc: akira yamada <akira@debian.org>,
Fumitoshi UKAI <ukai@debian.or.jp>, Shugo Maeda <shugo@debian.org>,
Taku YASUI <tach@debian.or.jp>
Subject: Re: Ruby 1.8 transition plan; debian-ruby
Hi,
Sorry for late response.
At Tue, 15 Jul 2003 15:48:35 +0300,
Dmitry Borodaenko wrote:
>
> Greetings!
>
> In the absence of a debian-ruby ML, I decided to address these questions
> to DDs with most important Ruby packages in Debian.
It would be better to do such discussion on debian-devel, since
lists admin guys said to me:
| You need to provide more information on how the list would be used, and
| show existing interest, e.g. by pointing out a few Ruby-related discussions
| on existing lists and having other people second the request.
(see Bug#183271)
> Is there, and if not, should there be a transition plan for Ruby 1.8?
> Should we wait until Ruby 1.8 is released, and then switch to 1.8
> completely (as most of us appear to do), or should we build two packages
> (for 1.6 and 1.8) for all of our libraries right now?
>
> It appears to me that akira-san is in favor of the second option, and I
> would follow that advice myself with my packages (at least with
> Ruby/DBI, since YAML is already packages with Ruby 1.8, and JTTUI is
> abandoned by upstream), but I would like other Debian/Ruby developers to
> follow, so that I could test my packages against, for example,
> libapache-mod-ruby1.8 and libpgsql-ruby1.8. Is that possible to form a
> consensus on this matter?
Yes, I think we need some consensus on the matter, and we should have
some ruby policy on debian.
IMHO, it would take much time to release sarge and ruby 1.8 will be released
so soon, sarge should have ruby 1.8 as default version of ruby
(unless ruby 1.10 or ruby 2.0 is released before sarge release:-)
So, I think we should build two packages for 1.6 and 1.8 for only
important libraries. Anyway, I've any idea what package is considered as
important for now.
> Also, if we decide to keep support for both versions for a while, should
> we use alternatives system to allow users to have both versions
> installed on the same machine, and to choose between them at runtime
> (like it is done with Tcl)? Will ruby1.8 be renamed into ruby, and
> current ruby renamed to ruby1.6 (possibly breaking some 1.6-specific
> code in dependent packages), or will we keep ruby1.8 name for the rest
> of its life (as with tcl8.x)?
Hmm, it seems Perl was named with versioned, but it is changed to
support only one version by perl with conflicting older version.
I think this is because perl (perl-base) is too important for debian
system. Maybe there ware discussion on lists.debian.org why perl do
like this, so we can learn some lessons from the discussion and the
decision.
Python is packaged as python2.1 and python2.2 and virtual package
python depends on default version of python (currently 2.2).
If we requires two different version co-exists, then it would be good
to follow python's way.
> Speaking of debian-ruby, here are some interesting stats:
>
> $ grep-available -sMaintainer ruby|sort|uniq|wc -l
> 32
> $ grep-available -sPackage ruby|wc -l
> 178
>
> That is not as much as Perl (467/1520) and Python (192/728), but is in
> the same league with Tcl(131/282), Java (68/244), PHP (69/192), and Lisp
> (48/193), and much better than Schema (19/32), Forth (17/26), and Caml
> (11/84). Of all mentioned languages, there are debian- lists only for
> Perl, Python, and Java communities.
>
> Question: do we need debian-ruby ML?
I think yes, so I submit as Bug#183271. However, lists admins want to see
how the new requested list will be used and they can't find any good
discussions on ruby in lists.debian.org.
So, please discuss on lists.debian.org (debian-devel is good?).
Regards,
Fumitoshi UKAI
----- End forwarded message -----
Reply to: