[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Bug#290705: ruby: Ruby is completly vivisected.

Trevor

1/16/2005 2:53:00 AM

Package: ruby
Version: 1.8.1-8
Severity: important

Repost from ruby-talk mailing list:
On Sat, 15 Jan 2005 14:56:10 +0900, Thursday
<nospam@nospam.nospam.nospam.nospam.org> wrote:

>> Thursday wrote:
>
>>> > Much thanks for the feedback.
>>> >
>>> > I think in this instance, another challenge is that the ruby
>>> > source
>>> > build provides more than the ruby1.8 package. Just one example
>>> > being
>>> > libzlib-ruby1.8.
>
>> oops


>> ruby1.8 provides these (incliding libzlib-ruby1.8):


>> ri1.8, ruby1.8-dev, libsdbm-ruby1.8, libtcltk-ruby1.8, ruby1.8,
>> libruby1.8, libsyslog-ruby1.8, libdl-ruby1.8, libstrscan-ruby1.8,
>> irb1.8, libdbm-ruby1.8, libiconv-ruby1.8, libzlib-ruby1.8,
>> libtk-ruby1.8, libreadline-ruby1.8, libxmlrpc-ruby1.8,
>> libyaml-ruby1.8,
>> libruby1.8-dbg, rdoc1.8, libwebrick-ruby1.8, libtest-unit-ruby1.8,
>> libpty-ruby1.8, libracc-runtime-ruby1.8, libgdbm-ruby1.8,
>> librexml-ruby1.8, libbigdecimal-ruby1.8, ruby1.8-examples,
>> ruby1.8-elisp, libsoap-ruby1.8, libdrb-ruby1.8, libcurses-ruby1.8,
>> liberb-ruby1.8, libopenssl-ruby1.8


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
13 Answers

leon breedt

1/16/2005 3:16:00 AM

0

On Sun, 16 Jan 2005 11:53:11 +0900, Trevor Wennblom <wenn0029@tc.umn.edu> wrote:
> 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

1/16/2005 10:53:00 AM

0

leon breedt schrieb:
> On Sun, 16 Jan 2005 11:53:11 +0900, Trevor Wennblom <wenn0029@tc.umn.edu> wrote:
>
>>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.

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

1/16/2005 10:56:00 AM

0

On Sun, 16 Jan 2005 12:16:06 +0900, leon breedt wrote:

> On Sun, 16 Jan 2005 11:53:11 +0900, Trevor Wennblom <wenn0029@tc.umn.edu>
> wrote:
>> 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.

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

1/16/2005 11:02:00 AM

0

On Sun, 16 Jan 2005 19:51:19 +0900, Kristof Bastiaensen
<kristof@vleeuwen.org> wrote:
> 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

1/16/2005 11:07:00 AM

0

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.
>
>
>>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 :/

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

1/16/2005 11:08:00 AM

0

Ha, you beat me too it

Sascha

Kristof Bastiaensen

1/16/2005 12:00:00 PM

0

On Sun, 16 Jan 2005 20:02:08 +0900, leon breedt wrote:

> On Sun, 16 Jan 2005 19:51:19 +0900, Kristof Bastiaensen
> <kristof@vleeuwen.org> wrote:
>> 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.

Kristof

Austin Ziegler

1/16/2005 12:49:00 PM

0

On Sun, 16 Jan 2005 19:51:19 +0900, Kristof Bastiaensen
<kristof@vleeuwen.org> wrote:
> On Sun, 16 Jan 2005 12:16:06 +0900, leon breedt wrote:
> > On Sun, 16 Jan 2005 11:53:11 +0900, Trevor Wennblom <wenn0029@tc.umn.edu>
> > wrote:
> >> 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.
> 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
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca

T. Onoma

1/16/2005 1:42:00 PM

0

On Sunday 16 January 2005 06:56 am, Kristof Bastiaensen wrote:
| On Sun, 16 Jan 2005 20:02:08 +0900, leon breedt wrote:
| > On Sun, 16 Jan 2005 19:51:19 +0900, Kristof Bastiaensen
| >
| > <kristof@vleeuwen.org> wrote:
| >> 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

1/16/2005 1:58:00 PM

0

On Sun, 16 Jan 2005 21:48:48 +0900, Austin Ziegler wrote:
> 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