Octave-forge-2004-11-16 is meant _solely_ for octave 2.1.62. It will not work on neither previous NOR LATER versions. Current version of octave in portage is 2.1.69. See http://sourceforge.net/project/showfiles.php?group_id=2888 Replicable: always. If you "emerge octave octave-forge" with e.g. an x86 keyword, you will not be able to use forge functions as interp1, unique and others. Solution: in sci-mathematics/octave-forge-2004-11-16-r1.ebuild, change the line DEPEND=">=sci-mathematics/octave-2.1.62 to DEPEND="=sci-mathematics/octave-2.1.62 This will make sure that the correct version is installed. A corresponding equality constraint should be maintained for future octave-forge ebuilds too.
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,
