Bug 99781 - sci-mathematics/octave-forge-2004-11-16-r1 does not enforce the right version of octave
|
Bug#:
99781
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: WONTFIX
|
Assigned To: sci@gentoo.org
|
Reported By: zenith@mpi-magdeburg.mpg.de
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: sci-mathematics/octave-forge-2004-11-16-r1 does not enforce the right version of octave
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-07-21 04:26 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.
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,
