Jon Peatfield wrote: > On Thu, 15 Nov 2007, Paul Johnson wrote: > >> I have a script that I run every night and it checks for a long list >> of R packages and installs what is needed. On a new SL5 system, I >> noticed that the script failed because the package "coda" was not >> available. "There's a mistake" I thought to myself, because coda is >> one of the heavily used packages for Bayesian MCMC modeling. >> >> It turned out that the CRAN current version of coda is set to ONLY >> compile for R >= 2.5. Since the SL5 version of R is 2.4, the package >> manager was not able to find the coda package. I updated R on the >> system to the version that is available in Fedora and then the package >> script worked fine. >> >> I understand the SL5 philosophy of preferring stable things, but since >> R is one of the "feature packages" that differentiates Scientific >> Linux from other RedHat EL descendants like CentOS, it seems important >> to me that you should keep R more up to date than most packages. >> >> I went to the SL website to try to enter this opinion, but I find it >> is necessary to log in and I can't find a place where I can register >> myself. What's up with that? > > SL currently provides R-2.5 in the 'testing' repository, so something like: > > yum --enablerepo=sl-testing update R > > should pick up the newer version (and not pull in any other unrelated > testing updates). > > I say *should* 'cos we upgraded to the 'testing' R some time ago so I > can't trivially test that I got the yum options right. Apologies if I did. > > Troy sent a message to the list the other day saying that he plans to > include an updated R in each new release of SL so SL51 will probably > have something fairly recent by the time it is released. > > Troy Dawson <[log in to unmask]> wrote: > >> I have thought of a plan for R. >> The problem is that we have two sets of users. Those that want the >> latest R and those that want the stable, this is what we use R. >> >> As each S.L. release comes out, we'll just check and see what the >> latest R is, and put it in that release. >> But we don't update the R in the older releases. So if a person wants >> to sit on whatever R came with S.L. 4.5, they can just stay at S.L. >> 4.5. Or just use the R in S.L. 4.5 and put it in their excludes line for >> yum. >> >> This will allow us to get a new version out every 6 months, which >> should keep at least a fair amount of the R users happy, I hope. > > I think that 6-monthly updates will certainly keep R fresh enough for > our users - they seem to start complaining if it is more than 12 months > old... :-) > Here is what I sent to scientific-linux-devel ------------------- The problem is that we have two sets of users. Those that want the latest R and those that want the stable, this is what we use R. As each S.L. release comes out, we'll just check and see what the latest R is, and put it in that release. But we don't update the R in the older releases. So if a person wants to sit on whatever R came with S.L. 4.5, they can just stay at S.L. 4.5. Or just use the R in S.L. 4.5 and put it in their excludes line for yum. This will allow us to get a new version out every 6 months, which should keep at least a fair amount of the R users happy, I hope. -------------------- Just so you know, I have put R 2.5.0 into rolling, it should go out with the beta, and I am working on R 2.6.0. It didn't compile on the first shot, so I need to check and see why. Hopefully it's something trivial. If I get it to compile before the beta goes out, I'll put it in. Troy -- __________________________________________________ Troy Dawson [log in to unmask] (630)840-6468 Fermilab ComputingDivision/LCSI/CSI DSS Group __________________________________________________