Re: Dependence of octave-forge on octave version

[Quentin Spencer]

Rafael Laboissiere wrote:

> * James R. Phillips <address@hidden> [2005-11-27 17:34]:
>
>  
>
> > I am preparing the new 2.1.72 octave release for cygwin.  I notice now that
> > most of the files in the octave-forge package are in a directory tree with the
> > previous octave  release version (2.1.71) encoded in the path, which means that
> > the octave-forge files are not (by default visible) within the new 2.1.72
> > release, even if they are present.
> >
> > This does not seem to be the case in Debian.  So I wonder - is octave-forge
> > when compiled truly bound to the version of octave installed on the system at
> > that time?  Or would it be compatible with later versions, as long as they
> > maintain the same abi?
> >
> > As it is, it appears I will have to release a new octave-forge version to go
> > with the new octave version.  Is there any easy way to prevent this happening
> > in the future?
> >
> > Advice/comments would be appreciated.
> >    
>
> In Debian, the *.m files are installed in /usr/share/octave/site/m/,
> while the *.oct files are installed in /usr/lib/octave/site/oct/api-v13/.
> This avoids using versioned installation directories.  The API version
> number changes less often than the releases of Octave (it has been
> api-v13 since 2.1.65).
>  

As the Fedora package maintainer, I guess I should repond here as well. 
I have always just done things the easy way, installing the files in the 
octave-forge default locations, which causes the situation you 
described. This means there is a new octave-forge release for every 
octave release, though sometimes they coincide anyway. However, I see 
that the Debian approach has some advantages, so I'm considering doing 
the same the next time I release an octave-forge. Is there an easy way 
of extracting the "api-v*" string from octave_config_info or something 
like it?

-Quentin