Summary: | sci-mathematics/octave-forge-2004-11-16-r1 does not enforce the right version of octave | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Federico Zenith <federico.zenith> |
Component: | New packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | cbm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Federico Zenith
2005-07-21 04:26:41 UTC
Can you provide a reference for "it will not work on neither previous NOR LATER versions"? My interpretation of the release information is that the octave-forge developers *tested* 2004-11-16 with octave-2.1.62 and 2006-06-13 (bug #99783) with octave-2.1.69. They also say "Many functions will also work on earlier versions of Octave." In my (limited) experience, many function also work with later releases of Octave. Well, one pointer is that octave-forge is repackages every time there is a release of octave; in theory the projects should not need to be synchronised. More specifically, however, you should try to install octave and octave-forge as they are in portage now, and try to access a forge function like interp1 or unique (or any other). It is possible that the compiling process of octave-forge has some hidden borkage that makes it install in a predetermined octave-X.y.z folder, no matter where octave really is, but I'm not sure. However, this happened to me a couple of times before with other combinations of octave and octave-forge, but I thought it was my system or some other problem. This is not obvious. The project announces some releases as compatible with one specific version, and others as compatible with a given version and all later versions. The configure script never seems to complain, though. To be on the safe side, I added octave-forge 2005-06-13 to Portage and made it depend specifically on Octave 2.1.69. Thanks for the hint. The ebuild you added to the tree needs the "Randmtzig patch" from Comment #3 of bug #99783. Also, the name of the patch as 2004.11.16.patch is misleading. I'm partial to the name "${PV}-mex-DESTDIR.patch" or something else thats descriptive. Anyway, please see bug #99783. Hi, in portage, as of monday 22nd of August, 9:50 CET, octave-forge-2004.11.16-r1 still has a >= dependency on Octave-2.1.62. Since 2.1.62 was removed, so should octave-forge-2004.11.16-r1, which is useless without it. The newer version of Octave-forge seems stable (have it on my machine). Thanks for the notice, Frederico, but we do not apply fixes retroactively unless it is necessary. As octave-forge-2004.11.16 seems to work fine with Octave, I am satisfied with the current state of affairs. The only solution would be, as you suggest, to remove octave-forge-2004.11.16 from the tree, but as it is the last stable version available for two architectures, this is out of the question. Once a newer version is marked stable, the ebuild will be removed. In the meantime, users who do not trust some combinations of Octave/octave-forge may elect to use the testing branch. Regards, |