Re: About the Ruby packages split: a concrete proposal
Ar 27/01/2005 am 14:06, ysgrifennodd Adeodato Simó:
> 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).
Yes, this makes sense. More fundamental changes in the way the packaging
works will have to wait until 2.0.
> - '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.
This seems sensible, although people who already have ruby installed and
don't want Tk will need to remove the ruby package before upgrading.
> - 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.
Yes, this is sound.
Another alternative is to make a package (ruby-libs, ruby-modules,
ruby-stdlib, etc.) which includes all of the standard library, but
doesn't declare a dependency on Tk. This way, all the libraries are in
one package, but packages which want to depend on Tk being available
will have to depend on ruby-libs (even if indirectly through the ruby
package), *and* Tk itself.
> - 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.
I see a problem with this:
If there is a package that depends on ruby, meaning "ruby and all the
standard library", and somebody has ruby-interpreter installed, then the
dependencies will be satisfied (because of the Provides) but the
necessary libraries will be missing.
> 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
Don't forget about packages which build-depend on ruby. I know of at
least one of these (ruby-gnome2). In that particular case, I think the
right thing would be switching to a dependency on ruby-interpreter if
your proposal was implemented.
As I see it, there are two ways to tackle the problem at hand:
- Maintain the current semantics of "apt-get install ruby", and add
another package "ruby-all" which installs Ruby and the standard
library.
- Make "apt-get install ruby" install Ruby and all of or some of the
standard library. (I.e. the route your proposal follows.)
There are, of course, advantages and disadvantages to both. I think I'm
currently in favour of the latter approach. If we are to go down this
path, I think your proposal, or something close to it, would be the way
to do it.
--
Dafydd
Reply to: