RE: Why Does Ruby on Debian Blow? (Was: Mongrel 3.15, Ubuntu


#1

One scanario where you might want to separate would be a productions
server running Ruby apps. Would you want or need irb, ri and rdoc on a
server where you’re not doing development? (that’s not a retorical
question I’m new to Ruby and Rails)

For the Ruby or Rails developer I agree it is a bit of a pain. I’m
planning on building a Debian Rails box so I might look at creating a
meta package and submit it to the package maintainer time permitting.
The downside is the long time it will take to get to a stable release
(the one problem I have with Debian).

Cheers

Ross


#2

On 5/4/06, Ross D. removed_email_address@domain.invalid wrote:

One scanario where you might want to separate would be a productions
server running Ruby apps. Would you want or need irb, ri and rdoc on
a server where you’re not doing development? (that’s not a retorical
question I’m new to Ruby and Rails)

That’s why I made the statement that I did:

And the problem is that irb1.8, ri1.8, and rdoc1.8 have no
business being separate. (At least the program files.)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The data files, I won't argue with.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Ok. ri and rdoc aren’t just commands. There are classes behind both.
Rdoc is a full-on document generator and templating system with an
interface to graphviz. (Limited purpose on that interface, but it’s
present nonetheless.) Ri is generated by rdoc, but the ri system is
also a YAML data lookup.

These things – and bits and pieces of irb – could be used by the
enterprising developer interested in reuse.

So … no.

There’s no good excuse for carving up the bits of the Ruby Standard
Library that aren’t bringing in X (e.g., Ruby’s Tk support).

I do not believe that zlib and OpenSSL are optional components of Ruby,
either. (zlib is required to make RubyGems run; there is an optional
security feature built into RubyGems that can be done with … OpenSSL.)

-austin


#3

“Ross” == Ross D. removed_email_address@domain.invalid writes:

One scanario where you might want to separate would be a productions
server running Ruby apps. Would you want or need irb, ri and rdoc on
a server where you’re not doing development?

Yes, you would. Because at some point, probably at 3AM on a Sunday
morning, the application is going to break down and you’ll want tools
available with which to fix it. If someone decided to save a few
measly kilobytes out of the machine’s several hundred gigabytes of
disk by not including those tools, you’re going to hate that someone
quite a lot.

Reverse the question, if you will. When does it ever hurt to have a
full Ruby installation there? The whole thing is only a few megabytes
(26MB for Ruby 1.9.0 on my OSX machine, and half of that is
documentation), you’d have to be extremely short on disk for it to
make a practical difference to take out parts of it. The Debian
variant of chopping it up into (according to a Debian proponent’s post
yesterday) twelve pieces (several of which don’t even mention Ruby
in their names!) seems to me to very much be a “one size fits nobody”
solution.

	     Calle D. <removed_email_address@domain.invalid>
	 http://www.livejournal.com/users/cdybedahl/
          Please pay no attention to the panda in the fridge.

#4

Calle D. wrote:

One scanario where you might want to separate would be a productions
server running Ruby apps. Would you want or need irb, ri and rdoc on
a server where you’re not doing development?

Yes, you would. Because at some point, probably at 3AM on a Sunday
morning, the application is going to break down and you’ll want tools
available with which to fix it. If someone decided to save a few
measly kilobytes out of the machine’s several hundred gigabytes of
disk by not including those tools, you’re going to hate that someone
quite a lot.
We are rather assuming that they were split out because of the space
argument, here… Maybe there was another issue? It wouldn’t be unlike
Debian to split a package over, for instance, legal or licencing issues.


#5

“Alex” == Alex Y. removed_email_address@domain.invalid writes:

We are rather assuming that they were split out because of the space
argument, here… Maybe there was another issue? It wouldn’t be
unlike Debian to split a package over, for instance, legal or
licencing issues.

Space is the only issue the Debian proponents have mentioned so far.
And when it comes to licensing issues I’ve only seem them distribute
cut-down packages with the content that was insufficiently pure for
them simply removed, not moved to a separate package. For example, to
the best of my knowledge you don’t get the full documentation for Perl
on a Debian system unless you download and install a source
distribution yourself.

	     Calle D. <removed_email_address@domain.invalid>
	 http://www.livejournal.com/users/cdybedahl/
"I don't know what art these programs are state-of; possibly 

macrame."
– Dr Richard A. O’Keefe, comp.risks


#6

On 05/05/06, Austin Z. removed_email_address@domain.invalid wrote:

I do not believe that zlib and OpenSSL are optional components of Ruby,
either. (zlib is required to make RubyGems run; there is an optional
security feature built into RubyGems that can be done with … OpenSSL.)

No doubt someone will correct me if I’m wrong,
but debian seem to have political reasons for breaking
out openssl - see:

http://lists.debian.org/debian-legal/2002/10/msg00111.html

for starters (realize that’s an old post, but it was still making my
life awkward
at Christmas).

I don’t have time for that sort of thing, so I stopped using it.


Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/


#7

It sure doesn’t cost too much to keep them there and it would be
great to know that Ruby is Ruby where ever you are.

The day you need to debug something on the server in a jiffy, it’s
great to have irb, ri and rdoc. Is it that expensive to have them
there compared to fragmenting Ruby and the troubles and difficulties
that may bring?

Any way, I think I’m done with this thread.

– G.