[Rd] R 2.1.1 slated for June 20

[Marc Schwartz]

On Thu, 2005-06-16 at 12:41 +0200, Martyn Plummer wrote:
> On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> > On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> > > Marc Schwartz <MSchwartz at mn.rr.com> writes:
> > > 
> > > > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > > > > 
> > > > > > The next version of R will be released (barring force majeure) on June
> > > > > > 20th, with beta versions available starting Monday.
> > > > > >
> > > > > > Please do check them on your system *before* the release this time...
> > > > > 
> > > > > Some things which it would be particularly helpful to have tested:
> > > > 
> > > > 
> > > > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3?  (These
> > > > >    often show up problems with bugs in the pre-release versions of
> > > > >    components such as X11 and compilers.)
> > > > 
> > > > 
> > > > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > > > yesterday.
> > > > 
> > > > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> > > > 
> > > > $ gcc --version
> > > > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> > > > 
> > > > and make check-all passes with no problems.
> > > > 
> > > > I have also installed all CRAN packages that do not require other 3rd
> > > > party drivers, etc. and there were no observed errors in those cases.
> > > > 
> > > > So far, so good.
> > > > 
> > > > If anything comes up, I will post a follow up.
> > > > 
> > > > Best regards,
> > > > 
> > > > Marc Schwartz
> > > 
> > > Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> > > my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> > > A couple of f95 warnings whooshed by during the compile, that was all.
> > > 
> > > By the way, I noticed that you can now "yum install R R-devel" and get
> > > everything straight from Fedora Extras.
> > 
> > Yep. Tom "Spot" Callaway is the FE maintainer for R.
> 
> I had a look at his RPM last night.  It includes a patch for gcc4, which
> fails to build R with the fairly aggressive optimizations used by
> rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> I'm not upgrading my work PC just yet, so I can't be sure).  I folded
> this into R-patched.  It's a shame he didn't send a bug report or, if he
> did, I missed it.
> 
> I also note he is using the patch that sets LANG=C, which is obsolete
> now that R supports utf-8 locales.  I'll write to him (cc Marc) to let
> him know about these changes.
> 
> The RedHat RPMS also use the shared library version of R.  I've been
> thinking about making this change myself, despite the substantial speed
> penalty, since I've seen a growing number of people recompiling to get
> the shared library.  The Red Hat choice forces my hand though: I don't
> want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> installed packages don't work anymore.  The $64,000 question is how many
> people are going to care about that 15-20% decrease in speed. Speak up
> now if it concerns you.

Martyn,

>From what I can tell, there is only one reason that the FC-E R RPM is
available as a shared library:

Tom had made the gnomeGUI CRAN package available as an RPM in FC-E,
which of course requires the above:

http://fedoraproject.org/extras/4/i386/repodata/repoview/R-gnomeGUI-0-2.1.0-4.html

I would defer to the opinion of others here, but given the rather
limited functionality of the R GNOME GUI and that not much if any work
is presently being done on it (is that correct?), does Tom's approach
really make sense?

Tom has also made RScaLAPACK available, but unless I am missing
something, I do not see a requirement that R be compiled as a shared
library for that package:

http://fedoraproject.org/extras/4/i386/repodata/repoview/R-RScaLAPACK-0-0.4.0-12.fc4.html

I am unclear as to the criteria for his package selection for FC-E and
what his future plans might be with respect to other CRAN packages being
made available via FC-E repos.

Perhaps Dirk (cc:'d here) and others on the Debian side of things have
some thoughts here. I know that there were exchanges in the past
regarding how to handle R and CRAN packages that were available directly
and/or from apt repos as .debs, relative to conflicts, etc.  I am not
sure if anything was ever resolved on those issues. If they have some
approaches that make sense, it would seem logical to leverage their
experience.

> > A lot of things for FC 4 have been moved to Extras and there are of
> > course new things (like R) there as well. The restrictions on non-GPL
> > components is still there, so things like MP3 functionality is available
> > via third party repos such as FreshRPMS, Livna, etc.
> > 
> > This was a "balancing" act between trying to reduce (manage) the size of
> > the main distro and reducing real or perceived redundancies in packages.
> > 
> > So, for example:
> > 
> > 1. Include OO.org in Core, but move Gnumeric to Extras
> > 
> > 2. Include Emacs in Core, but move XEmacs to Extras
> > 
> > Needless to say, that resulted in "emotional" discussions.
> 
> This underscores the fact Fedora, despite claiming to be a community
> project, is essentially Red Hat's rolling beta programme, and so must be
> more focused and less inclusive than Debian.  (Just an observation. I
> don't want to start a discussion on FOSS politics)

Yes, this is a sensitive area, but of course Debian has it's own
challenges at the moment, reflected in this article from this week by
Ian Murdock:

http://os.newsforge.com/os/05/06/14/1722241.shtml?tid=2

There is not a single "perfect" Linux distribution and I think that each
user has to make some decisions as to what their overarching
requirements are, which could be functional and philosophical. Based
upon those factors, each can select a distribution that makes sense.

Importantly, there are choices available.

Marc