I'm trying to find rpms for the latest released version of Ruby. After I pulled ruby-1.8.1-9.i386.rpm off of rubyforge, I tried to install it and ran into missing dependecies libruby.so.1.8 & ruby-libs = 20040219:1.8.1-9.
I know I'm probably missing something obvious. Help?
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
If all else fails, it's dirt simple to install from source,
generally nothing more than:
./configure
make
sudo make install
-- Markus
On Sun, 2004-09-26 at 14:12, Matt Lawrence wrote:
I'm trying to find rpms for the latest released version of Ruby. After I
pulled ruby-1.8.1-9.i386.rpm off of rubyforge, I tried to install it and
ran into missing dependecies libruby.so.1.8 & ruby-libs =
20040219:1.8.1-9.I know I'm probably missing something obvious. Help?
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
you need to install ruby-lib-xxxx.rpm too.
rpm -ivh ruby-xxx.rpm ruby-lib-xxx.rpm
Mohammad
On Sun, 2004-09-26 at 17:12, Matt Lawrence wrote:
I'm trying to find rpms for the latest released version of Ruby. After I
pulled ruby-1.8.1-9.i386.rpm off of rubyforge, I tried to install it and
ran into missing dependecies libruby.so.1.8 & ruby-libs =
20040219:1.8.1-9.I know I'm probably missing something obvious. Help?
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
--
Mohammad Khan <mkhan@lextranet.com>
Legal Computer Solutions, Inc.
[snip]
I know I'm probably missing something obvious. Help?
You can also try Ian McDonald's personal repository of RPM files for Redhat
http://caliban.org/files/redhat/RPMS/i386/
(you should have to pick the right ones for your platform)
Sometimes some libs are named differently across distros.
A package that was created as an RPM for Mandrake *may not*
work at all in Redhat and viceversa, due to different naming
and/or directory structure.
hope this helps,
--
--- vruz
I highly reccomend compiling from source RPMs if the distro the RPM was
built for is not your own.
Snag a .src.rpm, rpm --rebuild srpmfile -- you should get binaries.
If you want to tweak it, rpm -i srpmfile, then find the spec it spit out
(usually ruby.spec if the package name is ruby), edit the version
numbers, drop the source in the SOURCES directory, and then rpmbuild -ba
ruby.spec
Very useful, and since it was compiled on your distro, the dependencies
should resolve perfectly.
On Mon, 2004-09-27 at 06:12 +0900, Matt Lawrence wrote:
I'm trying to find rpms for the latest released version of Ruby. After I
pulled ruby-1.8.1-9.i386.rpm off of rubyforge, I tried to install it and
ran into missing dependecies libruby.so.1.8 & ruby-libs =
20040219:1.8.1-9.
Yeah, but I have another 16 systems that are scheduled to be installed.
Package managers are my friend.
And, yes, I've made this argument before. The vast majority of folks here are incredibly talented developers. However, managing production systems requires a different set of priorities.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
On Mon, 27 Sep 2004, Markus wrote:
If all else fails, it's dirt simple to install from source,
generally nothing more than:./configure
make
sudo make install
Ummm, that's rather obvious. However, it didn't seem to be on RubyForge.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
On Tue, 28 Sep 2004, Mohammad Khan wrote:
you need to install ruby-lib-xxxx.rpm too.
rpm -ivh ruby-xxx.rpm ruby-lib-xxx.rpm
I made more progress, but those RPMs want libdb-4.2 and RedHat Enterprise Server 3.0 is still using 4.1. At this point, I think I'll just put installing Ruby on hold, I don't really want to install unexpected versions of db4.
Thanks for the pointer, I will certainly use it on my systems at home.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
On Tue, 28 Sep 2004, vruz wrote:
[snip]
I know I'm probably missing something obvious. Help?
You can also try Ian McDonald's personal repository of RPM files for Redhat
http://caliban.org/files/redhat/RPMS/i386/
(you should have to pick the right ones for your platform)Sometimes some libs are named differently across distros.
A package that was created as an RPM for Mandrake *may not*
work at all in Redhat and viceversa, due to different naming
and/or directory structure.
I'm not suggesting you should do this, just curious as to what's
involved: creating your own RPM. If you built it from source on one
machine, can you easily create an RPM for managing all machines?
Cheers,
Gavin
On Monday, September 27, 2004, 8:31:31 AM, Matt wrote:
On Mon, 27 Sep 2004, Markus wrote:
If all else fails, it's dirt simple to install from source,
generally nothing more than:./configure
make
sudo make install
Yeah, but I have another 16 systems that are scheduled to be installed.
Package managers are my friend.
And, yes, I've made this argument before. The vast majority of folks here
are incredibly talented developers. However, managing production systems
requires a different set of priorities.
> [snip]
>> I know I'm probably missing something obvious. Help?
more [snips]
I made more progress, but those RPMs want libdb-4.2 and RedHat Enterprise
Server 3.0 is still using 4.1. At this point, I think I'll just put
installing Ruby on hold, I don't really want to install unexpected
versions of db4.
optionally, you can always try to --force --nodeps
(although that's far from being a recommendable practice)
if you don't use the ruby dbm modules, you shouldn't have a
problem, no ruby libs should interfere with the default RH
installation.
In any case, rpm -e will still work after forcing that install if
you don't get the expected results.
--
--- vruz
I gather making your own RPM fairly simple (disclaimer: I've
delegated the task but not done it myself).
The other option which we frequently use which dates back to before
RPMs is to have a build CD (which may in fact be an NFS mount) with a
script that runs a bunch of other scripts in a sub-directory tree. We
run this script at an appropriate point the setup of new machines. In
this set up, it really is dirt simple to have a script that does the
configure-make-make boogie but doesn't require manual intervention.
-- Markus
On Sun, 2004-09-26 at 16:33, Gavin Sinclair wrote:
On Monday, September 27, 2004, 8:31:31 AM, Matt wrote:
> On Mon, 27 Sep 2004, Markus wrote:
>> If all else fails, it's dirt simple to install from source,
>> generally nothing more than:
>>
>> ./configure
>> make
>> sudo make install> Yeah, but I have another 16 systems that are scheduled to be installed.
> Package managers are my friend.
> And, yes, I've made this argument before. The vast majority of folks here
> are incredibly talented developers. However, managing production systems
> requires a different set of priorities.I'm not suggesting you should do this, just curious as to what's
involved: creating your own RPM. If you built it from source on one
machine, can you easily create an RPM for managing all machines?
I know I got micro-flamed for making this same suggestion earlier
in this same thread, but why not compile from source? It’s quick, it’s
easy, and it is a lot cleaner than trying to force RPMs to go where they
aren’t happy. If you are in a multi-system production environment you
probably ought to have sufficently standardised builds to do this once &
make & push your own RPMs internally. In any case, in such an
environment you probably should be able to rebuild everything you run
from source anyway, so you can apply patches etc. in a timely manner.
-- MarkusQ
P.S. Note to the people who objected the last time I offered this
suggestion: I fully realise that “compile it!” isn’t the answer to
everything. But it is the canonical answer to “how can I get an
executable binary for this open source software?”
On Mon, 2004-09-27 at 15:56, vruz wrote:
[snip]
I know I’m probably missing something obvious. Help?
more [snips]
I made more progress, but those RPMs want libdb-4.2 and RedHat Enterprise
Server 3.0 is still using 4.1. At this point, I think I’ll just put
installing Ruby on hold, I don’t really want to install unexpected
versions of db4.optionally, you can always try to --force --nodeps
(although that’s far from being a recommendable practice)
if you don’t use the ruby dbm modules, you shouldn’t have a
problem, no ruby libs should interfere with the default RH
installation.
In any case, rpm -e will still work after forcing that install if
you don’t get the expected results.
Here is how I did my RPMs. I downloaded the ruby RPM for my distribution (Mandrake, ruby-1.6.7), extracted the spec file, put it in the newer ruby tarball, changed a few things to match the current version of ruby, compile into a RPM binary. I attached a modified version of the spec file that *should* work on any other RPM based distro.
% tar zxf ruby-1.8.1.tar.gz
% cp <file_from_attachement> ruby-1.8.1/ruby.spec
% tar zcf ruby-1.8.1.tar.gz ruby-1.8.1
% rpm -ta ruby-1.8.1.tar.gz
If everything went fine, you should now have a binary and a source RPMs in (adjust path to your distro and architecture): /usr/src/RPM/RPMs/i586 and /usr/src/RPM/SRPMS.
Hope it helps,
Guillaume.
Le 26 sept. 04, à 20:11, Markus a écrit :
On Sun, 2004-09-26 at 16:33, Gavin Sinclair wrote:
On Monday, September 27, 2004, 8:31:31 AM, Matt wrote:
On Mon, 27 Sep 2004, Markus wrote:
If all else fails, it's dirt simple to install from source,
generally nothing more than:./configure
make
sudo make installYeah, but I have another 16 systems that are scheduled to be installed.
Package managers are my friend.
And, yes, I've made this argument before. The vast majority of folks here
are incredibly talented developers. However, managing production systems
requires a different set of priorities.I'm not suggesting you should do this, just curious as to what's
involved: creating your own RPM. If you built it from source on one
machine, can you easily create an RPM for managing all machines?I gather making your own RPM fairly simple (disclaimer: I've
delegated the task but not done it myself).The other option which we frequently use which dates back to before
RPMs is to have a build CD (which may in fact be an NFS mount) with a
script that runs a bunch of other scripts in a sub-directory tree. We
run this script at an appropriate point the setup of new machines. In
this set up, it really is dirt simple to have a script that does the
configure-make-make boogie but doesn't require manual intervention.-- Markus
Unfortunately, that violates the "Principle Of Least Surprise". On a RedHat system I should be able to find all of the software installed by using "rpm -q". Even more importantly, the next sysadmin who touches the system should be able to do the same.
Right now I'm dealing with about 200 systems, most of which were installed by somebody else and handed over to my group to take care of. Many of the people doing the installations seemed to have been marginally competent. Quite a few of the other systems were set up by a guy who is brilliant, but in love with CMS. You know, it runs on IBM mainframes under VM. Those systems are really scarey to work on, so many things are set up so unexpectedly.
These are issues that developers generally don't have to deal with.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
On Mon, 27 Sep 2004, Markus wrote:
The other option which we frequently use which dates back to before
RPMs is to have a build CD (which may in fact be an NFS mount) with a
script that runs a bunch of other scripts in a sub-directory tree. We
run this script at an appropriate point the setup of new machines. In
this set up, it really is dirt simple to have a script that does the
configure-make-make boogie but doesn't require manual intervention.
You're absolutely correct, we should. However, The systems adminstration has been outsourced to a mega-corporation that only cares about extracting money from their clients. The project management is not only technically illiterate, they don't care about doing the job right. In fact, they are actively hostile to the technical folks on a regular basis.
Yeah, I knew what kind of weasels I was going to work for when I took the contract. It was better than bankruptcy. Barely. If anyone is looking for a talented & dedicated systems adminstrator to take care of Linux and AIX systems, please contact me.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
On Tue, 28 Sep 2004, Markus wrote:
I know I got micro-flamed for making this same suggestion earlier
in this same thread, but why not compile from source? It's quick, it's
easy, and it is a lot cleaner than trying to force RPMs to go where they
aren't happy. If you are in a multi-system production environment you
probably ought to have sufficently standardised builds to do this once &
make & push your own RPMs internally. In any case, in such an
environment you probably should be able to rebuild everything you run
from source anyway, so you can apply patches etc. in a timely manner.
Having a standard ruby RPM would do a lot to promote the wider
availabiltiy and distribution of ruby. Telling someone to install
from source does not handle every contingency.
On Mon, 27 Sep 2004 10:59:23 +0900, Matt Lawrence <matt@technoronin.com> wrote:
On Mon, 27 Sep 2004, Markus wrote:
> The other option which we frequently use which dates back to before
> RPMs is to have a build CD (which may in fact be an NFS mount) with a
> script that runs a bunch of other scripts in a sub-directory tree. We
> run this script at an appropriate point the setup of new machines. In
> this set up, it really is dirt simple to have a script that does the
> configure-make-make boogie but doesn't require manual intervention.Unfortunately, that violates the "Principle Of Least Surprise". On a
RedHat system I should be able to find all of the software installed by
using "rpm -q". Even more importantly, the next sysadmin who touches the
system should be able to do the same.Right now I'm dealing with about 200 systems, most of which were installed
by somebody else and handed over to my group to take care of. Many of the
people doing the installations seemed to have been marginally competent.
Quite a few of the other systems were set up by a guy who is brilliant,
but in love with CMS. You know, it runs on IBM mainframes under VM.
Those systems are really scarey to work on, so many things are set up so
unexpectedly.These are issues that developers generally don't have to deal with.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
Yeah, I knew what kind of weasels I was going to work for when I took the
contract. It was better than bankruptcy. Barely. If anyone is looking
for a talented & dedicated systems adminstrator to take care of Linux and
AIX systems, please contact me.
Don't let that grind you down, you'll always find people willing to
help you here, you have made a smart choice with ruby, we should
encourage that.
I don't have a RHEL here right now, but if I get my hands on one I'll
let you know.
Best luck in your endeavors,
--
--- vruz
In fact, it only handles one:
Somebody who...
knows where to get the source
knows how to compile the source
has the tools to compile the source
On Tue, 28 Sep 2004 00:21:27 +0900, Carl Youngblood <carl.youngblood@gmail.com> wrote:
Having a standard ruby RPM would do a lot to promote the wider
availabiltiy and distribution of ruby. Telling someone to install
from source does not handle every contingency.
--
Bill Guindon (aka aGorilla)
Just for the record, I (the original poster) didn't tell anyone to
do anything. I provided information to someone facing a problem
regarding 1) how I solved a similar problem (albeit with only a few
dozen machines) and 2) that it was not particularly difficult.
Further (and again for the record) I am quite willing to provide
what I hope to be helpful advice to anyone who asks politely. Handling
"every contingency" is beyond my purview. If you wish to have every
contingency handled I suspect you have a very long road to walk,
-- Markus
On Mon, 2004-09-27 at 08:21, Carl Youngblood wrote:
Telling someone to install
from source does not handle every contingency.
