I'm the current maintainer of the i386 R Ubuntu package. My situation
was the same as yours back when there were no updates (or
"backports") of R for Ubuntu -- on any platform. I decided to learn
how to build Debian/Ubuntu packages and then simply proposed to act
as maintainer to the CRAN people. I think they were glad to have
someone step up and they didn't ask any credentials (a good thing)
before accepting my offer. ;-)
I compile the packages on my machine in chroot jails, put them on a
web server with which CRAN synchronizes twice per day. (The only
difficulty I had was to convince our IT people to open the rsync port
to my machine.)
So, if anyone wants to take care of the 64 bit Ubuntu packages of R,
I think it would be most welcome by many.
Personally, I have no experience at all on a 64 bit architecture and
thus have no idea if the compilation process is any different from
the i386 one. The guidance I can provide is in the form of my build
scripts (already mentioned in a very recent thread; https://
stat.ethz.ch/pipermail/r-sig-debian/2007-July/000232.html). Actually,
there are very little few modifications to make to the fine Debian
packages. I merely add an entry in the changelog and change the
version number to fit Ubuntu's naming scheme. Just recently, I had to
fiddle a bit more to have 2.5.1 build on Dapper and Edgy.
Hope this helps.
Le 07-07-26 ? 10:18, Emmanuel Charpentier a ?crit :
> Dear sig-R-Debian
>
> I'd like to second Christophe Bonenfan's plea for an up-to-date
Ubuntu
> 64 (and maybe an up-to-date Debian 64) repository(ies). There seems to
> be no "easy" way, at least for Debian 64, to stay up-to-date on a
64
> bits Debian-derived system, "easy" meaning being able to keep a
> consistent system up-to-date with no local package creation and no
> "local", out-of-packaging, installation.
>
> The alternatives are not pretty :
>
> - keeping outdated versions expose you, among other unpleasant
> eventualities, to the risk of being Ripley'd for having the nerve to
> ask for help on R-help with an outdated system (not a pretty
> sight...) ;
>
> - a locally compiled R deprives you of most of the benefits of using a
> distribution (consistency, updates, etc..) ;
>
> - locally compiled packages is some work, that should not be
> duplicated
> if it can be avoided ;
>
> - following Debian unstable is a career in itself (been there, done
> that : not a decent pastime for a dental surgeon turned
> biostatistician
> turned dental surgeon...).
>
> So the right solution is probably to have this work done *once*,
> checked
> seriously, then to have the resultant packages put in some public
> repository (feisty-backports and lenny-proposed come to mind, but CRAN
> is probably also a good place).
>
> ISTR that Debian has (had ?) a script that allows to take a package's
> older source and newer upstream source in order to merge the latter in
> the former, thus having a more-or-less painless updating. Back in the
> days when I followed Debian unstable, this trick allowed me to update
> the wine packages, which were seriously lagging behind upstream ;
> however, for the life of me, I couldn't remember what this script is,
> and I do not know if it has been ported to Ubuntu.
>
> If someone was able to walk me through the steps necessary to build
> new
> Ubuntu (Debian ?) packages, and someone (else ?) could put them in the
> Right Place(s) (I'm neither a Debian Ordained Maintainer (C)(R)(TM)
> nor
> an Ubuntu MOTU (ditto)), I could pick the work of either building the
> new amd64 packages or checking them.
>
> Would you be so kind as to Cc' me : I'm following the lists through
> the
> archives...
>
> Emmanuel Charpentier
>
> _______________________________________________
> R-SIG-Debian mailing list
> R-SIG-Debian at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian