Prev: DBI:ODBC on Vista: "could not load driver"
Next: ERROR: no driver for sqlite3 found (Ruby 1.9.0 + Windows
From: Tom Cloyd on 23 Dec 2008 21:46
J�rg W Mittag wrote:
> Marc Heiler wrote:
>
>>> Forget apt-get for Ruby. Maybe one day that will work as most people
>>> expect it should. But today is not that day.
>>>
>> I do not think it ever will. How many years have gone by now since the
>> first user had the problem with this concerning ruby on debian at least?
>> 3 years?
>>
>> Debian Users will continue to have split-up packages, and as a result
>> continue to have all these problems which reoccur every some months on
>> the list here, or on a forum somewhere else. This is a fundamental flaw
>> in philosophy concerning packaging on Linux boxes altogether in fact.
>>
>
> Can you explain how this is a fundamental flaw in Linux packaging?
> TeX, Emacs, Perl, PHP, Python, Java, they all share most if not all of
> Ruby's challenges: all have their own directory layouts, their own
> search paths, their own library paths, their own versioning schemes,
> their own package managers, their own distribution formats, multiple
> different implementations, multiple different versions. Most have
> native C extensions. Most were not created with Linux package managers
> in mind -- heck, most were created before Linux package managers even
> existed.
>
> And yet, all of them work perfectly fine. All except Ruby.
>
> This reminds me of the guy on the freeway listening to the traffic
> channel and thinking to himself: "What are they talking about, a car
> driving the wrong way on the freeway? It's not *a* car, it's hundreds
> of them!"
>
> jwm
>
>
>
Interesting comment. I have to say that I don't see it as a flaw in
Linux packaging either. I began this thread by objecting to "secret
knowledge" - the knowledge that Rubygems, once you install it, cannot
function with something else which it never names and which I've never
heard of. There's always secret knowledge, of course, BUT, dammit, if
program X cannot do its thing without dependency Z, then I expect X to
take care of itself. I don't expect to have to do it myself. As an
ignorant amateur, that asking too much of me.

I see LOTS of things in Ruby taking care of themselves. But...when I go
to install Ruby, it comes WITHOUT RubyGems. Does that actually make
sense to anyone at all? If RubyGems is optional, why is it more optional
than all those exotic libraries that automatically come with Ruby. I'm
FAR more likely to need RubyGems, as a learner, than some library that
parses HTML header files or whatever (just making this UP!), or messes
with obscure aspects of networks. Priorities seem misplaced here.

The other side of it is this: if Ruby isn't going to come alive with
Rubygems (and, of course, all that IT needs to function), then it looks
like Rubygems needs to look out for itself. Otherwise, *I* have to it,
and I haven't a clue (well, I sure do now, of course - but why did I
have to run off the cliff 6 times to get this sorted out?). I protest
about this because I deeply love and respect Ruby. I want to push others
to try it. I don't want them to have some of these crazy problems I've
had. It doesn't seem necessary.

So, I'm back where I started. This particular problem just needs to be
fixed. I can't do it - I don't know enough. I'm in favor of making
things work. How about you?

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc(a)tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From: Justin Collins on 24 Dec 2008 00:46
Tom Cloyd wrote:
> J�rg W Mittag wrote:
>> Marc Heiler wrote:
>>
>>>> Forget apt-get for Ruby. Maybe one day that will work as most people
>>>> expect it should. But today is not that day.
>>>>
>>> I do not think it ever will. How many years have gone by now since
>>> the first user had the problem with this concerning ruby on debian
>>> at least? 3 years?
>>>
>>> Debian Users will continue to have split-up packages, and as a
>>> result continue to have all these problems which reoccur every some
>>> months on the list here, or on a forum somewhere else. This is a
>>> fundamental flaw in philosophy concerning packaging on Linux boxes
>>> altogether in fact.
>>>
>>
>> Can you explain how this is a fundamental flaw in Linux packaging?
>> TeX, Emacs, Perl, PHP, Python, Java, they all share most if not all of
>> Ruby's challenges: all have their own directory layouts, their own
>> search paths, their own library paths, their own versioning schemes,
>> their own package managers, their own distribution formats, multiple
>> different implementations, multiple different versions. Most have
>> native C extensions. Most were not created with Linux package managers
>> in mind -- heck, most were created before Linux package managers even
>> existed.
>>
>> And yet, all of them work perfectly fine. All except Ruby.
>>
>> This reminds me of the guy on the freeway listening to the traffic
>> channel and thinking to himself: "What are they talking about, a car
>> driving the wrong way on the freeway? It's not *a* car, it's hundreds
>> of them!"
>>
>> jwm
>>
>>
>>
> Interesting comment. I have to say that I don't see it as a flaw in
> Linux packaging either. I began this thread by objecting to "secret
> knowledge" - the knowledge that Rubygems, once you install it, cannot
> function with something else which it never names and which I've never
> heard of. There's always secret knowledge, of course, BUT, dammit, if
> program X cannot do its thing without dependency Z, then I expect X to
> take care of itself. I don't expect to have to do it myself. As an
> ignorant amateur, that asking too much of me.
>
> I see LOTS of things in Ruby taking care of themselves. But...when I
> go to install Ruby, it comes WITHOUT RubyGems. Does that actually make
> sense to anyone at all? If RubyGems is optional, why is it more
> optional than all those exotic libraries that automatically come with
> Ruby. I'm FAR more likely to need RubyGems, as a learner, than some
> library that parses HTML header files or whatever (just making this
> UP!), or messes with obscure aspects of networks. Priorities seem
> misplaced here.
>
> The other side of it is this: if Ruby isn't going to come alive with
> Rubygems (and, of course, all that IT needs to function), then it
> looks like Rubygems needs to look out for itself. Otherwise, *I* have
> to it, and I haven't a clue (well, I sure do now, of course - but why
> did I have to run off the cliff 6 times to get this sorted out?). I
> protest about this because I deeply love and respect Ruby. I want to
> push others to try it. I don't want them to have some of these crazy
> problems I've had. It doesn't seem necessary.
>
> So, I'm back where I started. This particular problem just needs to be
> fixed. I can't do it - I don't know enough. I'm in favor of making
> things work. How about you?
>
> t.
>

The next version of Ruby will/does come with RubyGems.
But how a Linux distro packages it all up is not something with the
developers of Ruby have control over (or very little, at least). One
alternative is for people to contribute packages for various systems,
but then you would have the "official" version (via your package
manager's sources) and the external version. Plus, somebody has to
maintain all that.
Now, installing via your particular Linux distro's packaging system is
just one way of installing Ruby. The Windows One-Click version, for
example, comes with RubyGems and a lot of other things that the regular
Ruby package does not. On the other hand, if you install straight from
source you never have to work about installing ruby-devel packages, but
then that comes with its own challenges.

-Justin

From: Florian Gilcher on 26 Dec 2008 03:34
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Dec 24, 2008, at 3:46 AM, Tom Cloyd wrote:
>
>
> Interesting comment. I have to say that I don't see it as a flaw in
> Linux packaging either. I began this thread by objecting to "secret
> knowledge" - the knowledge that Rubygems, once you install it,
> cannot function with something else which it never names and which
> I've never heard of. There's always secret knowledge, of course,
> BUT, dammit, if program X cannot do its thing without dependency Z,
> then I expect X to take care of itself. I don't expect to have to do
> it myself. As an ignorant amateur, that asking too much of me.
>
> ...

I think the problem is that Ubuntu relies on the Debian packages.
While Debian aims to be the system where an experienced user can
install exactly the installation parts he wants, Ubuntu tries to be
accessible and problem-free.

So, the packaging for Debian is perfectly fine for expert uses but
totally bad in the Ubuntu context. Thats exactly the reason why I'm
not an Ubuntu user. When it comes to usage beyond the standard
installation, it gets horrible because of the mismatch between the
ease of standard use and the true hassle of slightly more advanced use.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAklUlzEACgkQyLKU2FMxSOKKxQCfcAFRl04fxL7RHJdl1zIzhFPG
N8IAoIkPvde0tyW3a7vtvyZCdJcMviVk
=O+TY
-----END PGP SIGNATURE-----

From: Dave Bass on 26 Dec 2008 07:04
Justin Collins wrote:
> But how a Linux distro packages it all up is not something with the
> developers of Ruby have control over (or very little, at least).

Surely Ruby people should be talking to distro people, pointing out the
problems and suggesting fixes. It's in everyone's interest that Ruby be
easy to install.

I too have run into problems trying to install Ruby on Ubuntu. I don't
care whose fault it is, or what the problem is, I just want it to work
first time like other packages do. Is that really too much to ask?

David
--
Posted via http://www.ruby-forum.com/.

First  |  Prev  | 
Pages: 1 2 3
Prev: DBI:ODBC on Vista: "could not load driver"
Next: ERROR: no driver for sqlite3 found (Ruby 1.9.0 + Windows