I do not understand the mentality behind Debian package management, or Linux in general for that matter. Stop trying to read my mind. You do not know what I want. I will worry about my own dependencies and disk space.

Very MS of them.

I don’t know what is “MS” about it. That’s why a lot is split up in Debian so choice is at the users side.

Yes, and that would be fine if we were talking about third-party Ruby libraries – but this is the standard library. The standard library is part of Ruby. This is rubbish and nonsense.

Yes, but I don’t want to have any Tk libs which is a consequence of having libtk-ruby (or one big ruby-stdlib package). I’m also thinking of the future where Ruby stdlib will grow an even larger dependency tree. Hence my proposal. But that’s all beside the point! I’m all with you here that something should change as I have pointed out. I don’t want to argue with people who wish the same, it’s… pointless.

Paul, I think this discussion is pertinent to non-Debian Rubyists as well, inasmuch as we have to explain to users why our software doesn’t work with their Ruby.

PHP is often separated into extensions in many package managers. But look at how PHP is packaged: it comes with many extensions, but very few of those are installed by the default ./configure settings. So, in PHP ’s case, no one complains about the fragmentation of the core distribution into various packages.

But with Ruby this seems like a baby and bath water dilemma. Sure, exclude stuff like Tk which has external dependencies. But leave in the stuff that is insular. We count on all that stuff.

Paul, are you the Debian-Ruby packager?

I agree completely. What also changed the case is that Ruby 1.6’s stdlib was almost all small pure Ruby libs and with 1.8 and probably more in the future is attracting solid good useful libs but with dependencies.

I am for easy installing of the bunch (apt-get install ruby, done with stdlib and all), but also want to keep the choice of not installing all because of depends, since there are more types of users using it all.

I am not the Debian Ruby packager. Those Fumitoshi UKAI and Akira YAMADA , which IMO are the two most relevant people for this discussion, but of whom I haven’t heard a thing about this since August, sadly.

I am trying to get a Debian Ruby project going, to make it all as good as Perl and Python is now in Debian. That is were my interests lie.

Here are the email addresses. There is already a debian-ruby mailing list. debian-ruby@lists.debian.org From my point of view the point is already well-established (from mailing list + history last year) that the current ruby split causes a lot of problems. And there is already proposed a good solution that solves all problems using a Debian virtual package, much like is already done with several others in Debian. So that you can opt to install less, but can default to more on the important top-level “convenience” packages which will be appropriate for most users. ukai@debian.or.jp emiel@il.fontys.nl

Cheers, -Rudi

Ruby is a little split up on Fedora Core 3 as well.

1) ruby 2) ruby-libs 3) irb 4) ri 5) ruby-docs 6) ruby-tcltk 7) ruby-mode (emacs syntax) 8) ruby-devel 9) ruby-debuginfo

Again it would be a nice thing to simply have “ruby” in all its glory when I do:

yum install ruby

rather than

yum search ruby yum install ruby* yum install ri yum install irb

Oi it lost my formating, each of the packages should be on its own line, same with the yum’s at the end …. grumble

Robert, did you use the preview button?

That would have been far to sensible _why :)

I do still wonder why it kept some formating but I guess it was becuase it had newlines between the short lines, where the others didn’t …

On FC4 ‘yum install ruby’ will install ruby and ruby-libs and ‘yum install ir’ will install ir and irb.