Bug#290705: ruby: Ruby is completly vivisected.

[Trevor Wennblom]

Package: ruby
Version: 1.8.1-8
Severity: important

Repost from ruby-talk mailing list:


And just *what* excuse do the Debian maintainers give for this
inexcusable mess that they've made of Ruby? With perhaps the exception
of ruby1.8-examples, ruby1.8-elisp, and *maybe* ruby1.8-dev and
libruby1.8-dbg (I don't know what's in those), the rest off this stuff
is part of Ruby's core as defined by Matz. If 'ri' isn't installed
(not necessarily the data files, because ri represents program
capabilities, too), then any system without it doesn't actually have
Ruby.




-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages ruby depends on:
ii ruby1.8 1.8.1+1.8.2pre4-1 Interpreter of object-oriented scr

-- no debconf information

 

[leon breedt]

And just *what* excuse do the Debian maintainers give for this
inexcusable mess that they've made of Ruby? With perhaps the exception
of ruby1.8-examples, ruby1.8-elisp, and *maybe* ruby1.8-dev and
libruby1.8-dbg (I don't know what's in those), the rest off this stuff
is part of Ruby's core as defined by Matz. If 'ri' isn't installed
(not necessarily the data files, because ri represents program
capabilities, too), then any system without it doesn't actually have
Ruby.

-dev and -dbg packages make sense to be split out (headers, and debug
symbols if you want gdb backtraces), but i don't see the core
distribution of Python or Perl being broken up into so many bits, so i
have no idea why they've done it.

i.e. core Python package on Debian contains pretty much every module
(readline, zlib, syslog, and so forth) shipping with the standard
Python distribution.

leon

 

[Sascha Ebach]

-dev and -dbg packages make sense to be split out (headers, and debug
symbols if you want gdb backtraces), but i don't see the core
distribution of Python or Perl being broken up into so many bits, so i
have no idea why they've done it.

i.e. core Python package on Debian contains pretty much every module
(readline, zlib, syslog, and so forth) shipping with the standard
Python distribution.

That was a major irritation to me, too. But I thought they would do that
with everything (never checked). Now that I hear that they don't maybe
we can politely ask them to stop this. Anyone know who is the maintainer?

Sascha

 

[Kristof Bastiaensen]

-dev and -dbg packages make sense to be split out (headers, and debug
symbols if you want gdb backtraces), but i don't see the core distribution
of Python or Perl being broken up into so many bits, so i have no idea why
they've done it.

It does make sense, for example when the user wants a package that
is written in Ruby, but doesn't want to program in Ruby itself. In
this case having all the ri-documentation would just fill-up space.

i.e. core Python package on Debian contains pretty much every module
(readline, zlib, syslog, and so forth) shipping with the standard Python
distribution.

Yes, and that's why I have my harddisk cluttered with Python-stuff
that I probably will never use :/

leon

Kristof

 

[leon breedt]

It does make sense, for example when the user wants a package that
is written in Ruby, but doesn't want to program in Ruby itself. In
this case having all the ri-documentation would just fill-up space.

What if the same user wants to run a Ruby package that requires a core
module to be present? Now they have to walk the dependency tree.
Space-saving vs. convenience. Which is more likely to annoy end-users?

A compromise could be to have a virtual Ruby package that declares the
correct dependencies to have the same modules as would be gotten by
doing a core install from source, at least you could opt out and
delete the virtual package and extraneous modules if you wanted to.
I.e. instead of apt-get'ing tens of packages:

$ apt-get install ruby-core

As I recall, it was mentioned that even this compromise was not deemed
acceptable by the Debian maintainers...although this is complete
hearsay as I heard it on IRC, so, take it with a tonne of salt.

Leon

 

[Sascha Ebach]

Kristof Bastiaensen:

It does make sense, for example when the user wants a package that
is written in Ruby, but doesn't want to program in Ruby itself. In
this case having all the ri-documentation would just fill-up space.




Yes, and that's why I have my harddisk cluttered with Python-stuff
that I probably will never use :/

Hm, at least my time is more valuable than my disc space. Looking
everytime what I forgot to install just keeps me from working.

I understand that you want to be slim. So maybe we could ask them to add
a master package that would install everything. Like

apt-get install lib-ruby1.8-all

Now everybody could be happy, right?

Sascha

 

[Sascha Ebach]

Ha, you beat me too it

Sascha

 

[Kristof Bastiaensen]

What if the same user wants to run a Ruby package that requires a core
module to be present? Now they have to walk the dependency tree.
Space-saving vs. convenience. Which is more likely to annoy end-users?

Apt-get should normally calculate the dependencies just fine (in a stable
package).

A compromise could be to have a virtual Ruby package that declares the
correct dependencies to have the same modules as would be gotten by doing
a core install from source, at least you could opt out and delete the
virtual package and extraneous modules if you wanted to. I.e. instead of
apt-get'ing tens of packages:

$ apt-get install ruby-core

As I recall, it was mentioned that even this compromise was not deemed
acceptable by the Debian maintainers...although this is complete hearsay
as I heard it on IRC, so, take it with a tonne of salt.

That looks like a good solution to me. I have the impression that Debian
maintainers like to create smaller packages, to prevent installing
unnecessary files, so I don't see why they would find it unacceptable.

Kristof

 

[Austin Ziegler]

It does make sense, for example when the user wants a package that
is written in Ruby, but doesn't want to program in Ruby itself. In
this case having all the ri-documentation would just fill-up space.

Not at all. As I have pointed out in my original message that was
kindly copied to the Debian bug list, ri is *more* than just
documentation. It is the set of programs and libraries which comprise
ri at the command-line and behind the command-line. If I were to write
a program that used ri (or rdoc) and someone wanted to use it, it
wouldn't work on most folks's Debian installs -- because of the
idiotic way that the Debian packages have been split up.

The core libraries shouldn't be vivisected this way (that's a great
way of saying it, Trevor). If you want to provide the ri documentation
separate, okay -- I'll think you're being silly, but don't you *dare*
pretend to know how to package the core libraries better than the
people who use the lanaguage every day and the people who define the
language.

As a perfect example, the RubyGems mailing list has gotten at least
three reports of being unable to use RubyGems on Debian because
libzlib-ruby hasn't been installed because they installed what seemed
most sensible (ruby18). Oops. This is simply inexcusable.

Not only that, a few megs of disk space is nothing.

-austin

 

[trans. (T. Onoma)]

02:08 +0900, leon breedt wrote:
| > On Sun, 16 Jan 2005 19:51:19 +0900, Kristof Bastiaensen
| >
| >> It does make sense, for example when the user wants a package that is
| >> written in Ruby, but doesn't want to program in Ruby itself. In this
| >> case having all the ri-documentation would just fill-up space.
| >
| > What if the same user wants to run a Ruby package that requires a core
| > module to be present? Now they have to walk the dependency tree.
| > Space-saving vs. convenience. Which is more likely to annoy end-users?
|
| Apt-get should normally calculate the dependencies just fine (in a stable
| package).
|
| > A compromise could be to have a virtual Ruby package that declares the
| > correct dependencies to have the same modules as would be gotten by doing
| > a core install from source, at least you could opt out and delete the
| > virtual package and extraneous modules if you wanted to. I.e. instead of
| > apt-get'ing tens of packages:
| >
| > $ apt-get install ruby-core
| >
| > As I recall, it was mentioned that even this compromise was not deemed
| > acceptable by the Debian maintainers...although this is complete hearsay
| > as I heard it on IRC, so, take it with a tonne of salt.
|
| That looks like a good solution to me. I have the impression that Debian
| maintainers like to create smaller packages, to prevent installing
| unnecessary files, so I don't see why they would find it unacceptable.

But try uninstalling just one of those small dependencies and apt-get wants to
uninstall the whole kit-and-kaboodle. Argh... That's why I now have two
versions of YAML on my machine :[

T.

 

[Kristof Bastiaensen]

Not at all. As I have pointed out in my original message that was kindly
copied to the Debian bug list, ri is *more* than just documentation. It is
the set of programs and libraries which comprise ri at the command-line
and behind the command-line. If I were to write a program that used ri (or
rdoc) and someone wanted to use it, it wouldn't work on most folks's
Debian installs -- because of the idiotic way that the Debian packages
have been split up.

Ok, I see the problem.

The core libraries shouldn't be vivisected this way (that's a great way of
saying it, Trevor). If you want to provide the ri documentation separate,
okay -- I'll think you're being silly, but don't you *dare* pretend to
know how to package the core libraries better than the people who use the
lanaguage every day and the people who define the language.

I don't know if that was adressed to me, but don't get me wrong. All
I was saying that it is a good thing to seperate the packages that are
only needed for developing Ruby-code. If ri-code is needed for a working
system then it should be surely installed. But the ri data files
however should not be. They will not be used by anyone who just want
to run a Ruby-application, without ever wanting to program in Ruby
(such people do exist).

As a perfect example, the RubyGems mailing list has gotten at least three
reports of being unable to use RubyGems on Debian because libzlib-ruby
hasn't been installed because they installed what seemed most sensible
(ruby18). Oops. This is simply inexcusable.

Not only that, a few megs of disk space is nothing.

It all adds up. A few megs for Python, a few megs for Perl, a few
megs for *insert obscure language or library here*. Really, it
matters when everyone thinks like this.

Kristof

 

[Dick Davies]

It all adds up. A few megs for Python, a few megs for Perl, a few
megs for *insert obscure language or library here*. Really, it
matters when everyone thinks like this.

Yes, but these aren't just docs we're talking about - things like yaml,
webrick et al are in the base on 1.8. To me that's one of the big features
of 1.8, and having them split up into separate debs is a real pain.

 

[Sascha Ebach]

Kristof Bastiaensen:

It all adds up. A few megs for Python, a few megs for Perl, a few
megs for *insert obscure language or library here*. Really, it
matters when everyone thinks like this.

This is ridicolous. Have you looked at the prices for hard drives
lately? Debian is a full blown linux distribution, right? Or is it a
distribution that is supposed to be used from a floppy disc?

And if the *insert obscure language or library here* add up than simply
don't install *insert obscure language or library here*. Only install
Ruby with its core libraries. Everything in the distribution is core.
Everything else is tgz, gem or rpa.

Debian is such a wonderful system and apt-get simply rules, but, if this
vivisecting is not done for Perl and Python it shouldn't be done for
Ruby IMHO. Size arguements simply don't count. If you need space delete
files you don't need. Or simply make a compressed backup (for example of
the documentation files).

Can't there be some kind of compromise?

Sascha

 

[Esteban Manchado Velázquez]

[...]

-dev and -dbg packages make sense to be split out (headers, and debug
symbols if you want gdb backtraces), but i don't see the core
distribution of Python or Perl being broken up into so many bits, so i
have no idea why they've done it.

i.e. core Python package on Debian contains pretty much every module
(readline, zlib, syslog, and so forth) shipping with the standard
Python distribution.

That was a major irritation to me, too. But I thought they would do that
with everything (never checked). Now that I hear that they don't maybe
we can politely ask them to stop this. Anyone know who is the maintainer?

All that information is public:

Fumitoshi UKAI, akira yamada and Akira TAGOH are responsible for this Debian
package.

Please see http://packages.debian.org/unstable/interpreters/ruby. I guess the
best we can do is filing a bug against the "ruby" package. See
http://bugs.debian.org/ruby, where you can see the already filed bug (and
comments) by Trevor. But _please_, let's all be polite: we will have a higher
chance to achieve something if we are polite, after all, Debian is a
_volunteer_ organization.

Regards,