About the Ruby packages split: a concrete proposal
Hi all!
Given the late fuss about the Ruby packages being split in Debian, the
need for a working solution has become evident (more than it already
was). After some discussion in #debian-ruby, a concrete proposal is
ready for comments.
Paul van Tilburg, Andres Salomon and myself discussed the general
idea, and after some polishing of the details, Paul prepared sample
packages, which are now available in his repository [1], and tested
that the transition is smooth.
[1] deb http://people.debian.org/~paulvt/ruby ./
The modifications go to the 'ruby-defaults' source package, since as
we want this for sarge, there is no possibility of reverting the split
in the *1.8 ones (and that would have to be heavily discussed, anyway).
So, two new virtual packages get introduced, and the meaning of the
'ruby' virtual package changes. See the end of the mail for the
details, the explanation is:
- 'apt-get install ruby' will give a full ruby installation, which
should solve most complains people have about the split. So, the
principle of least surprise is followed: installing 'ruby' gives
you the full standard lib and an interpreter. This effectively
changes the semantics of the 'ruby' package, and has implications
for dependency handling; see below for the details.
- a new package ruby-core is introduced, that depends on _most_ of
the Ruby stdlib (Tcl/Tk libs are left out). At first, it was
thought of including here only the pure ruby libraries, so that no
dependencies outside libruby existed. However, as many of the
needed libraries were 'required' or 'important' or 'standard',
they have been included. Installing ruby-core, then, gives a very
reasonable, yet compact, ruby environment.
- finally, another new package is also created: ruby-interpreter,
which is equivalent to the old 'ruby' package (i.e., depends only
on rubyX.Y). As packages may depend on 'ruby' meaning "I only need
the interpreter", ruby-interpreter will Provide: ruby until all of
these dependencies can be changed.
Still, a bunch of packages have their 'ruby' dependency versioned,
for which the above is not enough (since versioned provides are
not supported). I can count 16 of these, using the following
command:
$ grep-available -e -FDepends '(^| +)ruby *\(' -ns Package
This does not mean that the proposed changes can't be made. Only,
that anybody having any of those packages installed will have to
temporarily install the full ruby stdlib until the packages switch
to depending on 'ruby-interpreter' (bugs should be filed).
There is also the more conservative approach of making a
'ruby-defaults' upload in which 'ruby-core' and 'ruby-interpreter'
get introduced, but 'ruby' is _not_ changed, file bugs, and
re-upload with 'ruby' changing its meaning after all packages have
been fixed.
Also, the Ruby folicy should have to be updated to reflect this. A
patch with a minimal set of required changes is attached.
The full details follow. I've put this document in [2], and labelled
it as "Version 1" to it so that any changes can be traced.
[2] http://the-swirl.org/~adeodato/debian/ruby/RubyDefaults.new
----------------------8<-----------------------------------------
Source: ruby-defaults
Package: ruby-interpreter
Provides: ruby
Depends:
ruby1.8
libruby
Package: ruby-core
Depends:
ruby-interpreter
irb
rdoc
libbigdecimal-ruby
libcurses-ruby [libncurses5 is 'required']
libdbm-ruby [libgdbm3 is 'important']
libdl-ruby
libdrb-ruby
liberb-ruby
libgdbm-ruby [libgdbm3 is 'important']
libiconv-ruby
libopenssl-ruby [libssl0.9.7 is 'standard']
libpty-ruby
libracc-runtime-ruby
libreadline-ruby [libreadline4 is 'standard']
librexml-ruby
libsdbm-ruby
libstrscan-ruby
libsyslog-ruby
libtest-unit-ruby
libwebrick-ruby
libxmlrpc-ruby
libyaml-ruby
libzlib-ruby [zlib1g is 'required']
Package: ruby
Depends:
ruby-core
libtcltk-ruby
libtk-ruby
Recommends:
ri
ruby1.8-examples
Suggests:
ruby-elisp
---------------------->8-----------------------------------------
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
-- Alan Kay
--- ruby-policy.sgml.old 2005-01-27 06:33:57.000000000 +0100
+++ ruby-policy.sgml 2005-01-27 06:42:00.000000000 +0100
@@ -13,7 +13,7 @@
<author>
<name>Fumitoshi UKAI</name>
</author>
- <version>version 0.0.1.4</version>
+ <version>version 0.0.2.0</version>
<abstract>
This document describes the packaging of Ruby within the Debian
@@ -116,7 +116,7 @@
</p>
<p>
- At any time, exactly one package, called <package>ruby</package>
+ At any time, exactly one package, called <package>ruby-interpreter</package>
must contain a binary <file>/usr/bin/ruby</file>, which is
symlink to the <file>/usr/bin/ruby<var>X</var>.<var>Y</var></file>,
the default version of Ruby.
@@ -285,7 +285,7 @@
<file>/usr/bin/ruby</file>.
Of course, if the package includes
ruby scripts using <tt>#!/usr/bin/ruby</tt>. it must depend
- on <package>ruby</package>.
+ on <package>ruby-interpreter</package>.
(FIXME: such scripts should be packaged separately?)
</p>
</sect>
@@ -298,10 +298,10 @@
<p>
Programs that can run with any version of Ruby should be started
with <tt>#!/usr/bin/ruby</tt>. They must also specify a
- dependency on <package>ruby</package>. They may specify a
+ dependency on <package>ruby-interpreter</package>. They may specify a
dependency with versioned like
- <tt>ruby (>= <var>X</var>.<var>Y</var>),
- ruby (<< <var>X</var>.<var>Y'</var>)</tt>,
+ <tt>ruby-interpreter (>= <var>X</var>.<var>Y</var>),
+ ruby-interpreter (<< <var>X</var>.<var>Y'</var>)</tt>,
where <var>Y'</var> >= <var>Y</var> + 3.
If <var>Y'</var> < <var>Y</var> + 3, then
you should reconsider that the program is really version
@@ -348,7 +348,7 @@
<package>ruby<var>X</var>.<var>Y</var>-dev</package> package;
for architecture independent
packages, it may be sufficient to depend on the
- <package>ruby</package> or
+ <package>ruby-interpreter</package> or
<package>ruby<var>X</var>.<var>Y</var></package> package.
</p>
</appendix>
Reply to: