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
__________________________________________________