Re: octave packages

[David Bateman]

Orion Poplawski wrote:
> David Bateman wrote:
>> Octave has to handle the packaging at some point otherwise Octave has no
>> knowledge of package and can't load and unload the packages from the
>> path as needed (think NaN package that is useful but not always).. Sorry
>> the "one package manager to rule them all" argument can not hold here
>> and the distribution packages will have to let Octave do at this part of
>> the job..
> 
> I still think you may need two classes of packages - one that is enabled
> by default upon install and all users automatically get them, and one
> that is installed but not available until "pkg load" or some such is
> done.  Maybe not, but it seems useful to me.

That is what the "pkg load auto" command that is in a PKG_ADD command
does. The packages flag their default behavior in the description and
those marked "Autoload: yes" are loaded at startup.


> 
>> My idea of the minimum at the moment is what is, and has been for a few
>> months, in the octave-forge CVS as the "make srpms" target. Orion has
>> pointed out that the effort I previously made to separate the
>> architecture dependent and independent files did go far enough and I
>> have a patch for that (see the message
>> http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-September/004057.html,
>>
>> though I've simpliied it a bit since its not fundamentally different),
>> that places the archiecture dependent code in
>>
>> <prefix>/libexec/octave/packages/<package>/getarch()
>>
>> and this can be set with a command to Octave by
>>
>> pkg prefix <prefix> <archprefix>
>>
>> to allow for builds that aren't preformed by root. I believe the only
>> change needed to the octave-forge "make srpms" target to make use of the
>> patch to pkg.m above is the patch attached, though I won't apply this
>> till the pkg.m patch is discussed...
>>
> 
> Trying to use these patches (to pkg.m and package_Makefile) , but I'm
> still seeing everything end up it /usr/share/octave/packages.  Are we
> missing setting -global? 

Ahhh, ok I'll look tomorrow.. I checked the install directly and it
worked, but didn't check the srpms.. Unfortunately this would mean a bit
of work on my part to package a release of Octave to test with in an RPM..

> Also, it looks like the oct files would go to
> /usr/libexec/octave/packages on 32-bit as well as 64-bit with this patch.

What would getarch return for a 32 and 64-bit machine? If we made it
return something different, then not necessarily.. At the moment its
based on

octave_config_info("canonical_host_type")

Does that differ for a 64-bit platform..

D.



> 
>