Skip to content

RPM support for package installation?

5 messages · Rhiannon L Weaver, Brian Ripley, Martin Maechler +1 more

Original
Rhiannon L Weaver
# 
Hello,

Tech question, I hope this has not been addressed before.  I searched help 
archives and looked for online help but came up empty-handed.

My question is: (short version) Is there a RPM-supported version of 
update.packages() for use with updating package libraries on managed 
multi-user Linux networks?

Details:

I put in a request for updating the version of R on one of the hosts on my 
work Unix network, which is managed by our IT department.  Current version 
is 2.1.0; I asked them to update to 2.4.1. The core update installed and I 
was able to test it, but the update had trouble loading the package 
"Matrix" for use with "lme4".  I don't recall the specific error (will 
check it out when the new version gets re-installed again and I can 
document it).  Other packages (lme, wavethresh, MASS) seemed to load 
without problems.

I think the Matrix problem can be solved by running update.packages() but 
when I requested the admin to update packages for the new version, they 
said that they need to do this via an RPM.  Specifically (and I'm not a 
network guru so my advice may not be entirely accurate):

me: I think if you have admin access you should be able to update the R 
packages by using the command update.packages() from within a running, 
updated version of R, and it will automatically check packages for new 
versions and update them.

admin: But this method moves us to an unsustainable host with locally 
installed packages.  The add-on packages need to be installed via an RPM.

As I understand it, RPM is like a kind of makefile for Linux machines. 
The help mentions need of -devel or -dev files for RPM installations and 
updates of the core software; is there a similar avenue I can point my 
admin to for package updates?  I'm not afraid of a little Linux, but I 
fear I am a bit out of my element on this one.

Currently the workaround is for them to install the new version and for me 
to download and maintain packages locally.

Thanks very much for your time,
-Rhiannon
Brian Ripley
# 
The problem is the speed with which R packages change.  My dept considered 
this, and decided against.  There have been something like 200 new 
versions of CRAN packages already this year.

Even if we provided automated wrappers to make source RPMs, someone would 
still have to build the binary RPMs for your (unstated) architecture and 
then install it.  Unless you use very few packages nor sysadmin is going 
to be happy with this approach.

It really is quite easy to have your own library and install packages 
there, and it will become easier in 2.5.0.  Your 'workaround' is the 
preferred solution for many sites including ours, although for our most 
popular architectures we also run a central site-library of popular 
packages (e.g. those used for teaching here).
On Tue, 6 Feb 2007, Rhiannon L Weaver wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Rhiannon L Weaver
    

    

      
      #
    

  


  

      
Hi,

Thanks for the clarification.  As long as the admins don't mind (which I 
guess they won't because it means they won't have to build RPMs or 
binaries), I will be okay with just using local versions of the libraries. 
I just wanted to make sure I wasn't missing something obvious (which is 
probably pretty likely in situations like this).  Thanks again for your 
help.

-Rhiannon

        
On Tue, 6 Feb 2007, Prof Brian Ripley wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        
Rhiannon> Hi,

    Rhiannon> Thanks for the clarification.  As long as the
    Rhiannon> admins don't mind (which I guess they won't
    Rhiannon> because it means they won't have to build RPMs or
    Rhiannon> binaries), I will be okay with just using local
    Rhiannon> versions of the libraries.  

You will be using local version of the  ** packages **
by installing them into your own library.  Try to be careful not
to confuse the two terms.

    Rhiannon> versions of the libraries.  I just wanted to make
    Rhiannon> sure I wasn't missing something obvious (which is
    Rhiannon> probably pretty likely in situations like this).
    Rhiannon> Thanks again for your help.

    Rhiannon> -Rhiannon

        
Rhiannon> On Tue, 6 Feb 2007, Prof Brian Ripley wrote:

        
>> The problem is the speed with which R packages change.
    >> My dept considered this, and decided against.  There have
    >> been something like 200 new versions of CRAN packages
    >> already this year.
    >> 
    >> Even if we provided automated wrappers to make source
    >> RPMs, someone would still have to build the binary RPMs
    >> for your (unstated) architecture and then install it.
    >> Unless you use very few packages nor sysadmin is going to
    >> be happy with this approach.
    >> 
    >> It really is quite easy to have your own library and
    >> install packages there, and it will become easier in
    >> 2.5.0.  Your 'workaround' is the preferred solution for
    >> many sites including ours, although for our most popular
    >> architectures we also run a central site-library of
    >> popular packages (e.g.  those used for teaching here).
    >> 
    >>

        
>> On Tue, 6 Feb 2007, Rhiannon L Weaver wrote:

        
>> 
    >>> Hello,
    >>> 
    >>> Tech question, I hope this has not been addressed
    >>> before.  I searched help archives and looked for online
    >>> help but came up empty-handed.
    >>> 
    >>> My question is: (short version) Is there a RPM-supported
    >>> version of update.packages() for use with updating
    >>> package libraries on managed multi-user Linux networks?
    >>> 
    >>> Details:
    >>> 
    >>> I put in a request for updating the version of R on one
    >>> of the hosts on my work Unix network, which is managed
    >>> by our IT department.  Current version is 2.1.0; I asked
    >>> them to update to 2.4.1. The core update installed and I
    >>> was able to test it, but the update had trouble loading
    >>> the package "Matrix" for use with "lme4".  I don't
    >>> recall the specific error (will check it out when the
    >>> new version gets re-installed again and I can document
    >>> it).  Other packages (lme, wavethresh, MASS) seemed to
    >>> load without problems.
    >>> 
    >>> I think the Matrix problem can be solved by running
    >>> update.packages() but when I requested the admin to
    >>> update packages for the new version, they said that they
    >>> need to do this via an RPM.  Specifically (and I'm not a
    >>> network guru so my advice may not be entirely accurate):
    >>> 
    >>> me: I think if you have admin access you should be able
    >>> to update the R packages by using the command
    >>> update.packages() from within a running, updated version
    >>> of R, and it will automatically check packages for new
    >>> versions and update them.
    >>> 
    >>> admin: But this method moves us to an unsustainable host
    >>> with locally installed packages.  The add-on packages
    >>> need to be installed via an RPM.
    >>> 
    >>> As I understand it, RPM is like a kind of makefile for
    >>> Linux machines.  The help mentions need of -devel or
    >>> -dev files for RPM installations and updates of the core
    >>> software; is there a similar avenue I can point my admin
    >>> to for package updates?  I'm not afraid of a little
    >>> Linux, but I fear I am a bit out of my element on this
    >>> one.
    >>> 
    >>> Currently the workaround is for them to install the new
    >>> version and for me to download and maintain packages
    >>> locally.
    >>> 
    >>> Thanks very much for your time, -Rhiannon
    >>> 
    >>> ______________________________________________
    >>> R-devel at r-project.org mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>> 
    >> 
    >> -- 
    >> Brian D. Ripley, ripley at stats.ox.ac.uk Professor of
    >> Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
    >> University of Oxford, Tel: +44 1865 272861 (self) 1 South
    >> Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax:
    >> +44 1865 272595
    >> 

    Rhiannon> ______________________________________________
    Rhiannon> R-devel at r-project.org mailing list
    Rhiannon> https://stat.ethz.ch/mailman/listinfo/r-devel

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Jeffrey J. Hallman
    

    

      
      #
    

  


  

      
I feel your pain.  At my workplace, the network administrators insist that
anything that is to be distributed across the network be packaged up in an
RPM.  I have my own library of packages accessible to my section members, but
when I want to make something available to everyone, I have to create an RPM.

After many trials and tribulations, here is the rpm spec file I created for
Prof. Ripley's RODBC package. A few things to note:

1. R-2.4.0 was installed in /opt/r-2.4.0 by an RPM called R-arc
2. I create /opt/r-2.4.0/lib/R/src and unpack the source package there, so
   my users can look at the original code if they want to.
3. The rpm does R CMD INSTALL pkg  twice: once when it is installing the rpm,
   and again in the post-install step. The reason for the second pass is to
   insure that the help index files get rebuilt with all of the packages that
   are installed in the production directory.

My other rpms are similar to this one.  With that, here is the spec file: