99781 2005-07-21 04:26 0000 sci-mathematics/octave-forge-2004-11-16-r1 does not enforce the right version of octave 2005-08-22 16:42:32 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED WONTFIX P2 normal --- 1 zenith@mpi-magdeburg.mpg.de sci@gentoo.org cbm@m.fsf.org zenith@mpi-magdeburg.mpg.de 2005-07-21 04:26:41 0000 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. cbm@m.fsf.org 2005-07-21 11:38:54 0000 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. zenith@mpi-magdeburg.mpg.de 2005-07-21 12:59:34 0000 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. ribosome@gentoo.org 2005-08-20 12:07:02 0000 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. cbm@m.fsf.org 2005-08-20 18:28:28 0000 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. zenith@mpi-magdeburg.mpg.de 2005-08-22 00:58:14 0000 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). ribosome@gentoo.org 2005-08-22 16:42:32 0000 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,