Bug 176762
| Summary: | rpy needs to be rebuilt for R-2.2.1-2.fc4 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alex Lancaster <alex> |
| Component: | rpy | Assignee: | José Matos <jamatos> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | CC: | extras-qa |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 0.4.6-4.fc4 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-01-06 01:17:21 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: | 176763 | ||
| Bug Blocks: | |||
It's looking for: ImportError: No module named _rpy2021 but rpy-0.4.6-3.fc4 only contains: /usr/lib/python2.4/site-packages/_rpy2020.so So it is in fact sensitive to the the subminor release, i.e. R-2.2.0 is not binary compatible with R-2.2.1. Does rpy need to be this sensitive the R version number to function? The package maintainer of R should co-ordinate releases with the rpy maintainer. ping... I have build new versions to satisfy the 2.2.1 R version. An automatic solution is difficult in the sense that if we have R version x.y.z an automatic build is safe if x and y remain the same but it will probably not work if y is incremented. (In reply to comment #3) > I have build new versions to satisfy the 2.2.1 R version. > > An automatic solution is difficult in the sense that if we have > R version x.y.z an automatic build is safe if x and y remain the same > but it will probably not work if y is incremented. I agree, that's why suggested an explicit (i.e. manual) dependency on a particular version of R, i.e. Requires: R=x.y.z. That way if both R and rpy are installed and R is updated, but rpy is not rebuilt, then "yum upgrade" will fail noisely saying that R can't be upgraded because of the dependent rpy. That would be far better than the current situation where R is upgraded causing rpy to silently fail, which may not be noticed immediately. Also the automated repoclosure script will pick up the dependency problem and the maintainer should be notified quickly. Updated package available, seems to work fine, but I may open up a new bug for adding a manual dep. on a particular version of R. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Galeon/2.0.0 Description of problem: rpy fails at run-time, probably needs to be rebuilt for the new R. It seems that it is sensitive to the minor release number for R, so an explicit dependency on a particular version of R should maybe added to the list of "Requires:" Version-Release number of selected component (if applicable): rpy-0.4.6-3.fc4 How reproducible: Always Steps to Reproduce: 1. python 2. from rpy import * Actual Results: $ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from rpy import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/rpy.py", line 51, in ? exec("import _rpy%s as _rpy" % RVER) File "<string>", line 1, in ? ImportError: No module named _rpy2021 Expected Results: rpy should have worked. Additional info: