Bug 591331
Summary: | Review Request: rpy1 - Python interface to the R language | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | José Matos <jamatos> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, i, jamatos, pingou, ron |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-09-27 22:35:59 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 528664 |
Description
José Matos
2010-05-11 22:21:52 UTC
This fails to build for me in both f14 and rawhide. Is it really necessary to force such a strict version dependency on the base R package? That sounds like a recipe for broken dependencies. Yes. We (me and Spot) tried several other strategies and this is the only one that is robust and works. In practice it does not matter much because every time that Spot rebuilds R he rebuilds rpy as well. Does the build fails if you update the required R version to 2.12.0? With an update R version to 2.12.1, it builds fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=2744369 Not sure why BuildFails is still in the whiteboard if this is building; I'll clear it, but 17 months later I'm not sure if it matters. Could you indicate if this is still something you'd still like to submit? Is there still any point in having the old rpy version around, given that it hasn't been part of the distribution in years? Are there still reasons to keep this alive artificially? Who would benefit from this ancient rpy? The issue is that rpy1 and rpy2 are different code bases. I still have code that uses rpy1 as far as possible (and reasonable) I like to have rpms for the packages I use. It simplifies a lot a setup of new machines. :-) And yes, I am still interested in having this again in the distribution. My term of comparison is in a sense debian (informed common sense weighting in naturally) and debian does have both rpy1 and rpy2. Both packages are maintained by Dirk Eddelbuettel. I know Dick and I have a respect for his technical options. Fails to build for me; it appears that this needs to be kept up to date with the current Fedora R version in order to be useful. You are right. :-) I have the patches for that, and I intend to apply them soon. There are several cases where the code has changed. I have already the debian patches and I will adapt them as I see it fits our rules. Thanks for your interest in this. You should package rpy2. Ignore my last comment, as rpy has version 2 in the repo. I'm curious about whether rpy1 is useful or not. The package is only useful for old code that uses it. The new version 2.3.4 at this moment has some kind of compatibility layer but that it implies some time to change the code and it is not a complete solution (it fails in some cases). Since this review has been open for so long I decided to withdraw it and place rpy1 in a copr: http://copr.fedoraproject.org/coprs/jamatos/rpy1/ |