Hi,
I've wrote initial draft of debian ruby policy
http://pkg-ruby.alioth.debian.org/ruby-policy.html/index.html
Comments are welcome.
First, I'll intent to package ruby-defaults soon, which provides ruby and
libruby packages in which this ruby policy documents is included, and
rename current ruby package to ruby1.6 (and libruby to libruby1.6, ...).
After doing that, we'll start 1.6->1.8 transition as written in above
ruby policy documents.
I'd also like to hear opinions about ruby 1.8 packaging, especially
from ruby package maintainers who maintain ruby modules package that are
included in upstream ruby 1.8 distribution. As you know, ruby 1.8
includes the following packages in upstream distribution, and now
ruby1.8 make these packages from ruby1.8 source package. Is this ok?
I'm wondering these modules will be released independently from ruby 1.8.x
release. If so, it may be a problem because we may want such modules
that are released separately from ruby 1.8, instead of ruby 1.8 bundled ones.
What do you think about it?
New
liberb-ruby1.8
libdl-ruby1.8
libbigdecimal-ruby1.8
libracc-runtime-ruby1.8 (-ruby1.7?)
akira yamada <akira@debian.org>
libwebrick-ruby1.8 (<- libwebrick-ruby)
libzlib-ruby1.8 (<- libzlib-ruby)
libopenssl-ruby1.8 (<- libopenssl-ruby)
libstrscan-ruby1.8 (<- libstrscan-ruby)
libdrb-ruby1.8 (<- drb?)
libiconv-ruby1.8 (<- libiconv-ruby)
libxmlrpc-ruby1.8 (<- xmlrpc4r?)
Joe Wreschnig <piman@debian.org>
libtest-unit-ruby1.8 (<- libtest-unit-ruby)
Dmitry Borodaenko <angdraug@debian.org>
libyaml-ruby1.8 (<- libyaml-ruby)
Oliver M. Bolzer <oliver@debian.org>
librexml-ruby1.8 (<- librexml-ruby)
At 05 Aug 2003 17:49:16 -0500,
Joe Wreschnig wrote:
> On Tue, 2003-08-05 at 12:12, Fumitoshi UKAI wrote:
> > 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).
>
> There was a bug about this at some point, which I can no longer find,
> where I suggested doing for Ruby what Python does. Which is essentially:
> - 'ruby' is a metapackage depending the current default version of Ruby
> for Debian.
> - 'rubyX.Y' is a specific version of Ruby. 'ruby' depends on one of
> these.
>
> - 'libfoo-bar-ruby' is a metapacakge depending on libfoo-bar-rubyX.Y,
> where X.Y is the default version of Ruby (the same as the one 'ruby'
> depends on).
> - 'libfoo-bar-rubyX.Y' is foo-bar for a specific version of Ruby. The
> above depends on one of these. (These packages may be unncessary if the
> directory tree I outlined below is used, and the package is
> version-independent.)
Hmm, I agree that it would be good.
> As for module include paths, they're less important since most Ruby
> modules query Ruby for the right information at build-time anyway, but
> I'd like to see version-independent directories, and also preferrably a
> tree under /usr/share, too. Say,
>
> These are arch-independent:
> - /usr/share/ruby for Ruby modules that work with any version.
> - /usr/share/ruby/X.Y for Ruby modules that depend on version X.Y.
Currently, ruby upstream doesn't support such version independent module
path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later
to support this?
> These are arch-dependent:
> - /usr/lib/ruby/version/X.Y/#{arch}-#{os} for all arch-dependent
> modules. I believe most architecture-dependent modules need to be
> recompiled for each version of Ruby anyway, and so a version-independent
> architecture-dependent directory makes no sense.
Yes, I agree.
Regards,
Fumitoshi UKAI
Attachment:
pgprRFcw5qlZ4.pgp
Description: PGP signature