Laurent Gautier skrev: > 2008/6/7 Dirk Eddelbuettel <[EMAIL PROTECTED]>: > >> On 5 June 2008 at 11:08, Laurent Gautier wrote: >> | The "issue" is with the .deb packager. >> | That means that R-2.6.2 was not around when the package was built (may >> | be it was not released then). >> >> It's a synchronisation issue. For Debian, where I maintain R, RPy, ..., >> I tend to rebuild RPy when a new R requires it. >> >> For Ubuntu, I guess this got overlooked. Someone from the Ubuntu or RPt >> communities need to step forward and look after this. >> > > Yes, I only meant that this is a synchronization detail. > > The listed contacts for both r-base and rpy ubuntu packages is: > Ubuntu MOTU Developers <[EMAIL PROTECTED]> > > I've contacted the package manager for rpy on Ubuntu, and he has uploaded new builds to Gutsy-proposed and Hardy-proposed. > >> | Currently rpy is building a C-level module for each version of R (and >> | is looking for >> | the matching module at run time). Greg and I started discussing on >> | that: the need >> | appeared because symbol names in R are changing through versions. >> | One possibility is to relax the one-to-one association between a >> | version of R and >> | a C-level module, and keep the same python module until the R symbol >> | names used in RPy change. >> >> It's messy. For littler (http://dirk.eddebuettel.com/code/littler.html) >> which is an R frontend for scripting or quick command-line use, I sometimes >> get by with not rebuilding. The 2.6.1 to 2.7.0 transition was seemless. But >> then I don't explicitly check for version strings the way RPy does which is >> prudent, but mau also leads to a couple of false rejections. >> > > So we roughly have two options: > a- hard-code the versions of R a front-end is accepting to work with > b- let the front-end discover if it is ok at run-time. > > a- will require a new build for each version of R (potentially > higher-energy for the maintainer of compiled builds), and may only > have the appearance of safety (symbols may remain the same but their > functionality change), while b- can be made safer by > - adding a "version >=" check > - distributing a check mechanism with the build, unit-tests would be > fine, so a user can check that everything is working before starting > critical work such as a R-front-end-controlled rocket to Pluto. Given > the number of switches R's ./configure has, and the number of > third-party library R links to, it is seemingly not realistic to > expect a rpy maintainer to check all possible scenarios before > validating an R version. > > > Just a thought, > > > L. > > >> Dirk >> >> -- >> Three out of two people have difficulties with fractions. >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> rpy-list mailing list >> rpy-list@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/rpy-list >> >> > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > rpy-list mailing list > rpy-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rpy-list >
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
