Re: Issues with build Fedora RPMs of octave packages

[Orion Poplawski]

David Bateman wrote:
> There is another issue with using LOCALAPIFILEDIR or something like it..
>  The default path of octave is set to contain these directories and all
> sub-directories of these. A better choice might be
>
> <libexec>/octave/packages/getarch()/<package>
>
> where getarch is a pkg sub-function
>
> function arch = getarch ()
>   persistent _arch = strcat (octave_config_info("canonical_host_type"), ...
>                              "-", octave_config_info("api_version"));
>   arch = _arch;
> endfunction
>
> as this directory will not be automatically load by load_path.cc
> (load_path::do_initialize)

I guess I don't follow this.  Don't we want the functions to be in the 
path?  Isn't that the point of installing and rpm version on the system, 
so that all users can automatically use it?  That's how the octave-forge 
rpm has worked to this point.

> The attached patch does this, but leaves the installations of oct-files
> for non system users in the same location.. Does this meet your needs?

Well, first issue is that RPMs are not built as root, so the conditional 
on "issuperuser()" doesn't work.

Currently the octave-forge package rpm makefile does something like:

pkg('prefix',$(DESTDIR)/OCTAVE_HOME()/share/octave);
pkg('install','$(PACKAGE)');

It seems like simply being able to do something like:

pkg('octpath',$(DESTDIR)/<libexec>/octave/packages/getarch()/<package>);

would be sufficient for RPM packaging (assuming that the octave-forge 
makefiles are changed to pass in this parameter).


--
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