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]> > | 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
