Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > RPM of Ruby 1.8.x

Reply
Thread Tools

RPM of Ruby 1.8.x

 
 
Matt Lawrence
Guest
Posts: n/a
 
      09-26-2004
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.



 
Reply With Quote
 
 
 
 
Markus
Guest
Posts: n/a
 
      09-26-2004
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.
>




 
Reply With Quote
 
 
 
 
Matt Lawrence
Guest
Posts: n/a
 
      09-26-2004
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.

-- Matt
It's not what I know that counts, it's what I can remember in time to use.



 
Reply With Quote
 
Gavin Sinclair
Guest
Posts: n/a
 
      09-26-2004
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?

Cheers,
Gavin




 
Reply With Quote
 
Markus
Guest
Posts: n/a
 
      09-27-2004
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 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




 
Reply With Quote
 
Guillaume Marcais
Guest
Posts: n/a
 
      09-27-2004
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 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 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
>
>
>





 
Reply With Quote
 
Guillaume Marcais
Guest
Posts: n/a
 
      09-27-2004
--Apple-Mail-3--170899248
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed

Now with the attachment attached

Guillaume.


--Apple-Mail-3--170899248
Content-Transfer-Encoding: 7bit
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="ruby.spec"
Content-Disposition: attachment;
filename=ruby.spec

Summary: Object Oriented Script Language
Name: ruby
Version: 1.8.1
%define subver 1.8
Release: 1
License: GPL
Group: Development/Other
BuildRequires: XFree86-devel gpm-devel ncurses-devel readline-devel tcl tk

Source: ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.1.tar.gz
#Source1: http://www.pragprog.com:8080/rubyfaq...aqall.html.bz2
#Source2: http://dev.rubycentral.com/downloads...ngRuby-0.4.tgz
URL: http://www.ruby-lang.org/
Packager: Pixel <(E-Mail Removed)>
BuildRoot: %{_tmppath}/%{name}-%{version}-root

%ifarch ppc
%define my_target_cpu powerpc
%else
%define my_target_cpu %{_target_cpu}
%endif

#%package doc
#Summary: Documentation for the powerful language Ruby
#Group: Development/Other
#Requires: %{name} = %version-%release

%package devel
Summary: Development file for the powerful language Ruby
Group: Development/Other
Requires: %{name} = %version-%release

%package tk
Summary: Tk extension for the powerful language Ruby
Group: Development/Other
Requires: %{name} = %version-%release

%description
Ruby is the interpreted scripting language for quick and
easy object-oriented programming. It has many features to
process text files and to do system management tasks (as in
Perl). It is simple, straight-forward, and extensible.

# %description doc
# Ruby is the interpreted scripting language for quick and
# easy object-oriented programming. It has many features to
# process text files and to do system management tasks (as in
# Perl). It is simple, straight-forward, and extensible.

# This package contains the Ruby's documentation

%description devel
Ruby is the interpreted scripting language for quick and
easy object-oriented programming. It has many features to
process text files and to do system management tasks (as in
Perl). It is simple, straight-forward, and extensible.

This package contains the Ruby's devel files.

%description tk
Ruby is the interpreted scripting language for quick and
easy object-oriented programming. It has many features to
process text files and to do system management tasks (as in
Perl). It is simple, straight-forward, and extensible.

This package contains the Tk extension for Ruby.

%prep
%setup -q

#FILELIST="ruby.1 \
# ext/extmk.rb.in \
# ext/curses/*.rb \
# ext/tcltklib/demo/*.* ext/tcltklib/sample/*.rb ext/tcltklib/*.euc \
# ext/tk/sample/*.rb \
# sample/*.*"
#for i in ${FILELIST}; do
# sed -e s#/usr/local/bin/#%{_bindir}/#g $i >$i.$$
# mv $i.$$ $i
#done

%build
echo '.text' | gcc -shared -o libdummy.so.0 -xassembler - -ltcl -ltk >& /dev/null && {
if %{_bindir}/ldd libdummy.so.0 | grep -q "lib\(tcl\|tk\).so"; then
echo "Your tcl/tk is broken, get one with verioning in the libraries."
exit 1
fi
rm -f libdummy.so.0
}

CFLAGS=`echo %optflags | sed 's/-fomit-frame-pointer//'`
#%configure --prefix=/usr --program-suffix=-%{version}
%configure --prefix=/usr
%make
make test

%install
rm -rf %buildroot
make DESTDIR=%buildroot install

install -d %buildroot%{_docdir}/%{name}-%{version}
cp -a COPYING* ChangeLog README* ToDo sample %buildroot%{_docdir}/%{name}-%{version}
#bzcat %{SOURCE1} > %buildroot%{_docdir}/%{name}-%{version}/FAQ.html

install -d %buildroot%{_datadir}/emacs/site-lisp
cp -a misc/ruby-mode.el %buildroot%{_datadir}/emacs/site-lisp

install -d %buildroot%{_sysconfdir}/emacs/site-start.d
cat <<EOF >%buildroot%{_sysconfdir}/emacs/site-start.d/%{name}.el
(autoload 'ruby-mode "ruby-mode" "Ruby editing mode." t)
(add-to-list 'auto-mode-alist '("\\\\.rb$" . ruby-mode))
(add-to-list 'interpreter-mode-alist '("ruby" . ruby-mode))
EOF

(cd %buildroot%{_docdir}/%{name}-%{version} ; tar xfz %{SOURCE2} ; cd Pro*; mv -f html/* . ; rm -rf html xml)

(cd %buildroot ; find usr/lib/%{name}/%{subver} ! -type d -printf "/%%p\n") > %{name}.list
(cd %buildroot ; find usr/lib/%{name}/%{subver} -type d -printf "%%%%dir /%%p\n") >> %{name}.list

perl -ni -e 'print if !m|/(tcl)?tk|' %{name}.list
perl -ni -e 'print if !m|%{my_target_cpu}-%{_host_os}/.*[ha]$|' %{name}.list

%clean
rm -rf %buildroot

%post
/sbin/ldconfig

%postun
/sbin/ldconfig

%files -f %{name}.list
%defattr(-, root, root)
%dir %{_docdir}/%{name}-%{version}
%{_docdir}/%{name}-%{version}/README
%{_bindir}/*
%dir %{_libdir}/%{name}/
%{_mandir}/*/*
%{_datadir}/emacs/site-lisp/*
%config(noreplace) %{_sysconfdir}/emacs/site-start.d/*

# %files doc
# %defattr(-, root, root)
# %{_docdir}/%{name}-%{version}/COPYING*
# %{_docdir}/%{name}-%{version}/ChangeLog
# %{_docdir}/%{name}-%{version}/README.*
# # %{_docdir}/%{name}-%{version}/FAQ.html
# %{_docdir}/%{name}-%{version}/ToDo
# %{_docdir}/%{name}-%{version}/sample
# %{_docdir}/%{name}-%{version}/ProgrammingRuby*

%files devel
%defattr(-, root, root)
%{_libdir}/%{name}/%{subver}/%{my_target_cpu}-%{_host_os}/*.[ah]

%files tk
%defattr(-, root, root)
%{_libdir}/%{name}/%{subver}/%{my_target_cpu}-%{_host_os}/tcltk*
%{_libdir}/%{name}/%{subver}/%{my_target_cpu}-%{_host_os}/tk*
%{_libdir}/%{name}/%{subver}/tcltk*
%{_libdir}/%{name}/%{subver}/tk*

%changelog
* Wed Jul 24 2002 Pixel <(E-Mail Removed)> 1.6.7-4mdk
- really rebuild for new readline

* Tue Jul 23 2002 Pixel <(E-Mail Removed)> 1.6.7-3mdk
- rebuild for new readline

* Thu May 30 2002 Gwenole Beauchesne <(E-Mail Removed)> 1.6.7-2mdk
- Ah, turns out to be built with gcc3.1 too
- Don't test for versioned tcl/tk libraries by name. There could be ld
scripts instead. Anyway, tcl/tk looks broken since they don't have
any SONAME.

* Tue Mar 19 2002 Pixel <(E-Mail Removed)> 1.6.7-1mdk
- new release

* Thu Feb 28 2002 Geoffrey Lee <(E-Mail Removed)> 1.6.6-2mdk
- Recompile to get versioned tcl/tk linking.

* Thu Dec 27 2001 Pixel <(E-Mail Removed)> 1.6.6-1mdk
- new version

* Fri Oct 5 2001 Pixel <(E-Mail Removed)> 1.6.5-1mdk
- new version

* Mon Jul 23 2001 Pixel <(E-Mail Removed)> 1.6.4-2mdk
- don't mess CFLAGS, just remove fomit-frame-pointer

* Mon Jun 4 2001 Pixel <(E-Mail Removed)> 1.6.4-1mdk
- new version

* Fri May 25 2001 Pixel <(E-Mail Removed)> 1.6.3-4mdk
- directories-are-not-executables

* Fri May 18 2001 Pixel <(E-Mail Removed)> 1.6.3-3mdk
- fix dadou ****ing up things (irb and emacs mode were not there anymore!)

* Fri Apr 20 2001 David BAUDENS <(E-Mail Removed)> 1.6.3-2mdk
- Fix build on PPC

* Sun Mar 25 2001 Pixel <(E-Mail Removed)> 1.6.3-1mdk
- new version

* Mon Mar 19 2001 Pixel <(E-Mail Removed)> 1.6.2.2-2mdk
- fix the ruby.el (\\. -> \\\\.)

* Thu Jan 25 2001 Pixel <(E-Mail Removed)> 1.6.2.2-1mdk
- new stable snapshot

* Wed Dec 27 2000 Pixel <(E-Mail Removed)> 1.6.2-2mdk
- fix extensions
- create %{name}-devel
- remove %{name}-extensions, but create %{name}-tk

* Tue Dec 26 2000 Pixel <(E-Mail Removed)> 1.6.2-1mdk
- new version

* Mon Nov 27 2000 Pixel <(E-Mail Removed)> 1.6.1-4mdk
- build again full optflags

* Wed Nov 8 2000 Pixel <(E-Mail Removed)> 1.6.1-3mdk
- build without -fomit-frame-pointer for time being
- capitalize summaries

* Mon Oct 2 2000 Pixel <(E-Mail Removed)> 1.6.1-2mdk
- fix mispelling

* Thu Sep 28 2000 Pixel <(E-Mail Removed)> 1.6.1-1mdk
- new version
- remove "--with-default-kcode=none", not more needed
- remove setting optflags to -O2, ruby doesn't crashes any more

* Tue Sep 19 2000 Pixel <(E-Mail Removed)> 1.6.0-1mdk
- new version

* Wed Aug 23 2000 Pixel <(E-Mail Removed)> 1.4.6-6mdk
- add packager

* Tue Aug 22 2000 Pixel <(E-Mail Removed)> 1.4.6-5mdk
- nicer site-start.d/ruby.el (use add-to-list)

* Tue Aug 22 2000 Pixel <(E-Mail Removed)> 1.4.6-4mdk
- fix missing %%config

* Tue Aug 22 2000 Pixel <(E-Mail Removed)> 1.4.6-3mdk
- use %{_sysconfdir}/emacs/site-start.d for the ruby-mode.el

* Fri Aug 18 2000 Pixel <(E-Mail Removed)> 1.4.6-2mdk
- rebuild (fredlsux)

* Fri Aug 18 2000 Pixel <(E-Mail Removed)> 1.4.6-1mdk
- new version
- remove menu

* Mon Aug 07 2000 Frederic Lepied <(E-Mail Removed)> 1.4.5-6mdk
- automatically added BuildRequires

* Wed Jul 19 2000 Pixel <(E-Mail Removed)> 1.4.5-5mdk
- rebuild with clean clean_menus

* Wed Jul 19 2000 Pixel <(E-Mail Removed)> 1.4.5-4mdk
- macroization
- BM

* Thu Jul 13 2000 Pixel <(E-Mail Removed)> 1.4.5-3mdk
- fix %%URL

* Sun Jun 25 2000 Pixel <(E-Mail Removed)> 1.4.5-2mdk
- rebuild (src.rpm got lost )

* Fri Jun 23 2000 Pixel <(E-Mail Removed)> 1.4.5-1mdk
- new version

* Wed Jun 14 2000 Pixel <(E-Mail Removed)> 1.4.4-1mdk
- new version

* Mon Apr 10 2000 Pixel <(E-Mail Removed)> 1.4.3-6mdk
- fix group for doc

* Mon Mar 27 2000 Pixel <(E-Mail Removed)> 1.4.3-5mdk
- add menu

* Sat Mar 25 2000 Pixel <(E-Mail Removed)> 1.4.3-4mdk
- new group + cleanup

* Wed Feb 16 2000 Pixel <(E-Mail Removed)> 1.4.3-3mdk
- build with no charset conversion (was kanji

* Mon Feb 14 2000 Pixel <(E-Mail Removed)> 1.4.3-2mdk
- added the reference manual and FAQ in doc
- moved the lib/README in ext

* Mon Feb 14 2000 Pixel <(E-Mail Removed)> 1.4.3-1mdk
- mandrake adaptation and spliting in -/doc/extensions

* Wed Dec 08 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.4.3

* Mon Sep 20 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.4.2 (Sep 1

* Fri Sep 17 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.4.2

* Tue Aug 17 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.4.0

* Fri Jul 23 1999 Atsushi Yamagata <(E-Mail Removed)>
- 2nd release
- Updated to version 1.2.6(15 Jul 1999)
- striped %{prefix}/bin/ruby

* Mon Jun 28 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.2.6(21 Jun 1999)

* Wed Apr 14 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.2.5

* Fri Apr 09 1999 Atsushi Yamagata <(E-Mail Removed)>
- Updated to version 1.2.4

* Fri Dec 25 1998 Toru Hoshina <(E-Mail Removed)>
- Version up to 1.2 stable.

* Fri Nov 27 1998 Toru Hoshina <(E-Mail Removed)>
- Version up to 1.1c9.

* Thu Nov 19 1998 Toru Hoshina <(E-Mail Removed)>
- Version up to 1.1c8, however it appear short life

* Fri Nov 13 1998 Toru Hoshina <(E-Mail Removed)>
- Version up.

end of changelog shortened, hope you japs won't kill a froggy for this

--Apple-Mail-3--170899248
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed


Le 26 sept. 04, =E0 21:16, Guillaume Marcais a =E9crit :

> Here is how I did my RPMs. I downloaded the ruby RPM for my=20
> distribution (Mandrake, ruby-1.6.7), extracted the spec file, put it=20=


> in the newer ruby tarball, changed a few things to match the current=20=


> version of ruby, compile into a RPM binary. I attached a modified=20
> version of the spec file that *should* work on any other RPM based=20
> 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=20
> RPMs in (adjust path to your distro and architecture):=20
> /usr/src/RPM/RPMs/i586 and /usr/src/RPM/SRPMS.
>
> Hope it helps,
> Guillaume.
>
> Le 26 sept. 04, =E0 20:11, Markus a =E9crit :
>
>> 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=20
>>>> installed.
>>>
>>>> Package managers are my friend.
>>>
>>>> And, yes, I've made this argument before. The vast majority of=20
>>>> folks here
>>>> are incredibly talented developers. However, managing production=20=


>>>> 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=20
>> 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
>>
>>
>>

>
>


--Apple-Mail-3--170899248--


 
Reply With Quote
 
Matt Lawrence
Guest
Posts: n/a
 
      09-27-2004
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.



 
Reply With Quote
 
Carl Youngblood
Guest
Posts: n/a
 
      09-27-2004
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 <(E-Mail Removed)> 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.
>
>



 
Reply With Quote
 
Mohammad Khan
Guest
Posts: n/a
 
      09-27-2004
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 <(E-Mail Removed)>
Legal Computer Solutions, Inc.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Need an example program that implements rpm -pql via import rpm Steven W. Orr Python 1 03-04-2011 04:21 PM
pystone: pydotorg's RPM scores better than Fedora 2's RPM Zhi Min Python 0 06-11-2004 08:40 AM
Re: Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM andupgrade procedure? Cliff Wells Python 1 10-13-2003 01:03 PM
Python 2.3.2 RPM's for Redhat 8.0 or Python source RPM and upgrade procedure? Scott Chapman Python 0 10-03-2003 05:43 PM
Ruby 1.8.0 rpm? Hal Fulton Ruby 5 10-01-2003 09:15 PM



Advertisments