Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby
At Mon, 4 Aug 2003 18:02:52 +0300,
Dmitry Borodaenko wrote:
>
> 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?
Currently, there are no such policy or guidelines. There are policies
for each specific languages such as perl, python, java, emacsen,
however, it seems that they have somewhat different approaches.
I think it is impossible or very difficult to make general policy.
Anyway, it would be very helpful to make a guideline that
suggests the answers for the following questions.
> 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?
Since ruby 1.8.0 was released recently, ruby developers will go to
ruby 1.8.x, so that we, ruby maintenance team (akira, tagoh, ukai),
are discussing about how to deal with Ruby 1.8 transition and trying to make
debian ruby policy soon.
For now, ruby package provides /usr/bin/ruby of ruby 1.6.x, and
ruby1.8 package provides /usr/bin/ruby1.8 of ruby 1.8.x. Someone
want to use /usr/bin/ruby of ruby 1.8.x, so we're considering to use
alternatives for /usr/bin/ruby to choice either ruby1.6, ruby1.8 (or any
other version of ruby in future).
I wonder we should rename ruby package to ruby1.6 package and ruby package
for meta package for default version of ruby now. It requires package renaming
which is somehow troublesome, so I suspect it's worth to do it.
Anyway, I don't think we'll change ruby1.8 to ruby in the future, and
ruby becomes meta package for default version of ruby after ruby 1.6.x
is removed from unstable.
The default include paths of each ruby version are as follows:
% ruby -e 'puts $:'
/usr/local/lib/site_ruby/1.6
/usr/local/lib/site_ruby/1.6/i386-linux
/usr/local/lib/site_ruby
/usr/lib/ruby/1.6
/usr/lib/ruby/1.6/i386-linux
.
% ruby1.8 -e 'puts $:'
/usr/local/lib/site_ruby/1.8
/usr/local/lib/site_ruby/1.8/i386-linux
/usr/local/lib/site_ruby
/usr/lib/ruby/1.8
/usr/lib/ruby/1.8/i386-linux
.
So, libraries/modules of ruby should use
- /usr/local hierarchy for local system admins. packages must not use it
- /usr/lib/ruby/<version>/<gnu-type> for architecture dependent module packages
- /usr/lib/ruby/<version>/ for architecture independent module packages
As you can see, we don't have version independent directories, except
/usr/local/lib/site_ruby, so that library/module for ruby should be
packaged
- one package that installs files in /usr/lib/ruby/1.8 and
symlinks to /usr/lib/ruby/1.6, when the library/module can work
on both version of ruby
- as two packages for each ruby version, lib*-ruby and lib*-ruby1.8
when we need different script/shlib for each ruby version.
If the package is important and many packages depend on the package,
the package should be packaged for both ruby 1.6 and ruby 1.8.
If the package is not so important and usually it is used solely,
it may be packaged for only ruby 1.8.
Anyway, in due course of time, we'll remove all ruby 1.6 related
packages from unstable.
Ruby programs basically should use #!/usr/bin/ruby as shell magic, but
if the program depends on specific version of ruby, for example ruby 1.8,
use #!/usr/bin/ruby1.8.
Comments, suggestions are welcome.
Regards,
Fumitoshi UKAI
> --
> 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 -----
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: