Re: Issues with build Fedora RPMs of octave packages

[David Bateman]

Orion Poplawski wrote:
> 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.

We can have a package that is installed but not loaded. An example might
be the NaN package that changes the behavior of a number of basic Octave
functions to ignore NaN values. In most cases you want the core Octave
versions, but if you need the others and the NaN package is installed,
running

pkg load nan

will install them on the path, and when you are done

pkg unload nan

will remove them from the path. If the oct-files are under
LOCALAPIFILEDIR, then Octave assumes that they should be installed in
the load_path::do_initialize function independent of what the pkg
function wants to be done.

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

Humm ok, if you specify

pkg -global install <package>.tar.gz

then we should endeavour to do the same thing. It doesn't at the moment.

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

The comes to the same thing as the "-global" flag. However, thinking
about it a bit more there are other issues. Consider the case of having
a system installed octave package with some oct-files and at the same
time having a different user installed package with some oct-files. The
base name for the install directory will be different, but the user
should expect that both sets of oct-files will be available if the
packages are loaded. To me this means that the information to find the
directories containing the oct-files must be code in the "descriptions"
structure saved to the "octave_packages" file...

This then begs a new question, what exactly is the goal of having
architecture dependent and independent directories at all? The logic
seems to be that you can have one copy of the independent files and
multiple copies of the architecture dependent files, one for each
installation of which the version of octave is run. Therefore, I see
three solutions

1) The "octave-packages" file contains only the prefix for the location
of the oct-files and getarch() is added to the end. In this case a
better hierarchy would be

$(DESTDIR)/<libexec>/octave/packages/<package>/getarch()

though does that meet the FHS? This is my preferred solution as make the
multiple architecture dependent installation would just involve copying
the architecture dependent directory to the appropriate location.

2) We have different "octave-package" files per architecture. with the
paths to the oct-files hard-coded. I don't like this as it goes against
the logic of having a single installation with mutliple architecture
dependent directories.

3) Have the "octave-packages" file contain multiple entries for the
location of the architecture dependent files for each package; One for
each architecture supported. This is not fundamentally different from
1), except that the installation process of mutliple architecture would
need to have "octave_packages" modified and that should be done by
"pkg", when in fact this stuff would better be dealt with by the
distributions package manager...

I've not had much time to try and implement case 1), but will try over
the weekend.. Any comments?

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

If the next octave-forge is for 2.9.14 then we shouldn't change the
octave-forge makefiles yet... Should we wait for an octave-forge release
till this is settled?

D.


>