RPM of Ruby 1.8.x

Discussion in 'Ruby' started by Matt Lawrence, Sep 26, 2004.

  1. 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.
     
    Matt Lawrence, Sep 26, 2004
    #1
    1. Advertising

  2. Matt Lawrence

    Markus Guest

    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.
    >
     
    Markus, Sep 26, 2004
    #2
    1. Advertising

  3. 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.
     
    Matt Lawrence, Sep 26, 2004
    #3
  4. 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
     
    Gavin Sinclair, Sep 27, 2004
    #4
  5. Matt Lawrence

    Markus Guest

    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
     
    Markus, Sep 27, 2004
    #5
  6. 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
    >
    >
    >
     
    Guillaume Marcais, Sep 27, 2004
    #6
  7. --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/rubyfaqall.html.bz2
    #Source2: http://dev.rubycentral.com/downloads/files/ProgrammingRuby-0.4.tgz
    URL: http://www.ruby-lang.org/
    Packager: Pixel <>
    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 <> 1.6.7-4mdk
    - really rebuild for new readline

    * Tue Jul 23 2002 Pixel <> 1.6.7-3mdk
    - rebuild for new readline

    * Thu May 30 2002 Gwenole Beauchesne <> 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 <> 1.6.7-1mdk
    - new release

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

    * Thu Dec 27 2001 Pixel <> 1.6.6-1mdk
    - new version

    * Fri Oct 5 2001 Pixel <> 1.6.5-1mdk
    - new version

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

    * Mon Jun 4 2001 Pixel <> 1.6.4-1mdk
    - new version

    * Fri May 25 2001 Pixel <> 1.6.3-4mdk
    - directories-are-not-executables

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

    * Fri Apr 20 2001 David BAUDENS <> 1.6.3-2mdk
    - Fix build on PPC

    * Sun Mar 25 2001 Pixel <> 1.6.3-1mdk
    - new version

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

    * Thu Jan 25 2001 Pixel <> 1.6.2.2-1mdk
    - new stable snapshot

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

    * Tue Dec 26 2000 Pixel <> 1.6.2-1mdk
    - new version

    * Mon Nov 27 2000 Pixel <> 1.6.1-4mdk
    - build again full optflags

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

    * Mon Oct 2 2000 Pixel <> 1.6.1-2mdk
    - fix mispelling

    * Thu Sep 28 2000 Pixel <> 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 <> 1.6.0-1mdk
    - new version

    * Wed Aug 23 2000 Pixel <> 1.4.6-6mdk
    - add packager

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

    * Tue Aug 22 2000 Pixel <> 1.4.6-4mdk
    - fix missing %%config

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

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

    * Fri Aug 18 2000 Pixel <> 1.4.6-1mdk
    - new version
    - remove menu

    * Mon Aug 07 2000 Frederic Lepied <> 1.4.5-6mdk
    - automatically added BuildRequires

    * Wed Jul 19 2000 Pixel <> 1.4.5-5mdk
    - rebuild with clean clean_menus

    * Wed Jul 19 2000 Pixel <> 1.4.5-4mdk
    - macroization
    - BM

    * Thu Jul 13 2000 Pixel <> 1.4.5-3mdk
    - fix %%URL

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

    * Fri Jun 23 2000 Pixel <> 1.4.5-1mdk
    - new version

    * Wed Jun 14 2000 Pixel <> 1.4.4-1mdk
    - new version

    * Mon Apr 10 2000 Pixel <> 1.4.3-6mdk
    - fix group for doc

    * Mon Mar 27 2000 Pixel <> 1.4.3-5mdk
    - add menu

    * Sat Mar 25 2000 Pixel <> 1.4.3-4mdk
    - new group + cleanup

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

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

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

    * Wed Dec 08 1999 Atsushi Yamagata <>
    - Updated to version 1.4.3

    * Mon Sep 20 1999 Atsushi Yamagata <>
    - Updated to version 1.4.2 (Sep 18)

    * Fri Sep 17 1999 Atsushi Yamagata <>
    - Updated to version 1.4.2

    * Tue Aug 17 1999 Atsushi Yamagata <>
    - Updated to version 1.4.0

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

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

    * Wed Apr 14 1999 Atsushi Yamagata <>
    - Updated to version 1.2.5

    * Fri Apr 09 1999 Atsushi Yamagata <>
    - Updated to version 1.2.4

    * Fri Dec 25 1998 Toru Hoshina <>
    - Version up to 1.2 stable.

    * Fri Nov 27 1998 Toru Hoshina <>
    - Version up to 1.1c9.

    * Thu Nov 19 1998 Toru Hoshina <>
    - Version up to 1.1c8, however it appear short life :p

    * Fri Nov 13 1998 Toru Hoshina <>
    - 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--
     
    Guillaume Marcais, Sep 27, 2004
    #7
  8. 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.
     
    Matt Lawrence, Sep 27, 2004
    #8
  9. 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 <> 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.
    >
    >
     
    Carl Youngblood, Sep 27, 2004
    #9
  10. 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 <>
    Legal Computer Solutions, Inc.
     
    Mohammad Khan, Sep 27, 2004
    #10
  11. Matt Lawrence

    Bill Guindon Guest

    On Tue, 28 Sep 2004 00:21:27 +0900, Carl Youngblood
    <> 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.


    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

    --
    Bill Guindon (aka aGorilla)
     
    Bill Guindon, Sep 27, 2004
    #11
  12. Matt Lawrence

    Markus Guest

    On Mon, 2004-09-27 at 08:21, Carl Youngblood wrote:
    > Telling someone to install
    > from source does not handle every contingency.


    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
     
    Markus, Sep 27, 2004
    #12
  13. Matt Lawrence

    Bill Guindon Guest

    Matt Lawrence <> wrote:
    > I'm trying to find rpms for the latest released version of Ruby.


    Carl Youngblood <> 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.


    Markus <> wrote:
    > 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.


    Your answer is a valid one, and may even be the best one for Matt's situation.

    I can't speak for Carl, but my comment was meant to support the
    creation of packages. I'm not saying "install from source" is bad
    advice, I'm saying I wish there were more alternatives.

    Having burned a weekend (2 wks ago) trying to get the perfect setup to
    install/compile mod_ruby and Arrow on Win32 -- without success -- I
    may be a bit jaded :/

    --
    Bill Guindon (aka aGorilla)
     
    Bill Guindon, Sep 27, 2004
    #13
  14. 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


    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.
     
    Matt Lawrence, Sep 27, 2004
    #14
  15. Matt Lawrence

    vruz Guest

    [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
     
    vruz, Sep 27, 2004
    #15
  16. 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 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.
     
    Matt Lawrence, Sep 27, 2004
    #16
  17. Matt Lawrence

    vruz Guest

    > > [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
     
    vruz, Sep 27, 2004
    #17
  18. Matt Lawrence

    Markus Guest

    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.
     
    Markus, Sep 28, 2004
    #18
  19. 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.


    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.
     
    Matt Lawrence, Sep 28, 2004
    #19
  20. Matt Lawrence

    vruz Guest

    > 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
     
    vruz, Sep 28, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Scott Chapman
    Replies:
    0
    Views:
    360
    Scott Chapman
    Oct 3, 2003
  2. Cliff Wells
    Replies:
    1
    Views:
    351
    Paul Boddie
    Oct 13, 2003
  3. Zhi Min
    Replies:
    0
    Views:
    411
    Zhi Min
    Jun 11, 2004
  4. Steven W. Orr
    Replies:
    1
    Views:
    288
    Steven W. Orr
    Mar 4, 2011
  5. Hal Fulton

    Ruby 1.8.0 rpm?

    Hal Fulton, Oct 1, 2003, in forum: Ruby
    Replies:
    5
    Views:
    94
    Ian Macdonald
    Oct 1, 2003
Loading...

Share This Page