Re: Issues with build Fedora RPMs of octave packages

[Orion Poplawski]

David Bateman wrote:
> The binary architecture dependent files are under a separate directory in
>
>
> arch = strcat (octave_config_info("canonical_host_type"), ...
>                  "-", octave_config_info("api_version"));
>
> /usr/share/octave/packages/%name-%version/%arch
>
> Where should they be to meet the FHS? The only constraint I see on their
> placement is that it would be better to have each packages architecture
> dependent files in a separate directory. This for the PKG_ADD command
> issue below.

According to the FHS:

/usr/share : Architecture-independent data

Currently the Fedora octave packages put the .oct files into 
LOCALAPIOCTFILEDIR, for example:

/usr/libexec/octave/2.9.14/oct/i386-redhat-linux-gnu

Possibly this should get changed to

/usr/lib[64]/octave/%version/oct

depending on how you feel about libexec.  libexec is generally for 
programs and scripts that are only executed by other programs, not 
libraries.

> > I have made some hacks to split the .oct files into
> > LOCALAPIOCTFILEDIR, but this bring up an issue with the recommended
> > format of PKG_ADD:
> >
> > autoload ("airy_Ai_deriv", fullfile (fileparts (mfilename
> > ("fullpath")), "gsl_sf.oct"));
> >
> > Which expects the PKG_ADD file to be in the same directory as the .oct
> > files, which is not the case with the split.
> Unfortunately this the only way that will be guaranteed to work. There
> was some discussion of this on the maintainers list in the with
> something like
>
> autoload ("airy_Ai_deriv", which("gsl_sf"));
>
> being suggested. However the issue with this is that if there happens to
> be another function by the same name on the users path as gsl_sf, but
> before gsl_sf, then it will be selected for the autoload first. This
> means that the autoload will be dependent on the users path. This is not
> acceptable. This is also why autoload now requires absolute paths..
>
> An alternative might be to modify the autoload such that
>
> autoload ("airy_Ai_deriv", "gsl_sf")
>
> looks in the same directory as the PKG_ADD file that contains it first
> and only afterwards looks in the users path. This fixes the issue of the
> user path dependency on autoload but still means the PKG_ADD files have
> to be in the same directory as gsl_sf.oct..
>
> Other suggestions..

Why not get the path inserted at install time?  That's essentially the 
hack I've done to my octave-forge package, but it would be better if 
this could get supported automatically.

Source PKG_ADD would look something like:

autoload("funct","@OCTPATH@/myfuncts.oct");

and @OCTPATH@ gets substituted at install time.


--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  address@hidden
Boulder, CO 80301              http://www.cora.nwra.com