Package: ruby
Version: 1.8.1-8
Severity: important
Repost from ruby-talk mailing list:
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):
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
···
On Sat, 15 Jan 2005 14:56:10 +0900, Thursday <nospam@nospam.nospam.nospam.nospam.org> wrote:
-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
···
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.
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
···
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:
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?
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
···
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.
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
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
···
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.
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,
···
On Sun, Jan 16, 2005 at 07:53:16PM +0900, Sascha Ebach wrote:
[...]
>-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?
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
···
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:
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
···
On Sun, 16 Jan 2005 21:48:48 +0900, Austin Ziegler wrote:
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.
···
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.
> 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.
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.
···
--
'The old 'give em a Linux box and they think they're Jean-Luc Picard' syndrome.'
-- Pete Bentley
Rasputin :: Jack of All Trades - Master of Nuns
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).
