[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave packages
From: |
David Bateman |
Subject: |
Re: octave packages |
Date: |
Tue, 25 Sep 2007 00:58:58 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
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.
>
>
- Re: feature freeze -> 3.0 release, (continued)
- Re: feature freeze -> 3.0 release, David Bateman, 2007/09/21
- Re: feature freeze -> 3.0 release, Søren Hauberg, 2007/09/22
- Re: feature freeze -> 3.0 release, Shai Ayal, 2007/09/22
- Re: feature freeze -> 3.0 release, Thomas Weber, 2007/09/23
- Re: feature freeze -> 3.0 release, Shai Ayal, 2007/09/23
- Re: feature freeze -> 3.0 release, Thomas Weber, 2007/09/23
- Re: feature freeze -> 3.0 release, Søren Hauberg, 2007/09/23
- Re: feature freeze -> 3.0 release, Thomas Weber, 2007/09/23
- Re: feature freeze -> 3.0 release, David Bateman, 2007/09/23
- Re: octave packages, Orion Poplawski, 2007/09/24
- Re: octave packages,
David Bateman <=
- Re: octave packages, Tom Holroyd, 2007/09/24
- Re: octave packages, David Bateman, 2007/09/24
- Re: octave packages, Orion Poplawski, 2007/09/25
- Re: octave packages, David Bateman, 2007/09/25
- Re: octave packages, Orion Poplawski, 2007/09/25
- Re: octave packages, David Bateman, 2007/09/26
- Re: octave packages, David Bateman, 2007/09/26
- Re: octave packages, David Bateman, 2007/09/24
- Re: feature freeze -> 3.0 release, Rafael Laboissiere, 2007/09/24
- Re: feature freeze -> 3.0 release, orion, 2007/09/23