[Pkg-octave-devel] Re: OctavePackaging

[David Bateman]

Rafael Laboissiere wrote:
> [Cc:ing to pkg-octave-devel.  I think that there may be other people
> interested on this discussion]
> 
> * Thomas Weber <thomas.weber.mail at gmail.com> [2007-05-11 08:43]:
> 
>> I'll describe the current idea I'm following (which is uh 'copied' from the 
>> way the Apache webserver configuration is handled in Debian). 
>>
>> The packages are built using opkg and then split into arch-dependent (.oct, 
>> binaries) and arch-independent (.m, data) stuff in separate directories [2]. 
>> These directories are then written into a simple textfile, that is copied in 
>> the directory /etc/octave.d/. On startup, Octave reads every file in this 
>> directory and adds the directories given there to its loadpath. 
>>
>> Now, the problem you sketch above can be handled. In this case, there wouldn't 
>> be any file in /etc/octave.d/, but only two subdirectories:
>> 	/etc/octave.d/enabled
>> 	/etc/octave.d/installed
>> Packages installed by dpkg drop their path-file into the installed/ directory. 
>> If they are activated by default, they install a symlink to this package in 
>> enabled/, otherwise they don't do nothing.
> 
> I definitely like this design.  Please go ahead with the implementation.
> Also, please add your ideas to our Wiki.


Ok, then take the NaN package, it drops its directory in the installed
directory, but not in the enabled directory. So now its installed, but
not available to the user at start-up, which is normal. How then does
the user request access to these functions? With opkg the user does
"pkg('load',<package>)" and the loading of the package is forced. I see
no easy way to duplicate this in this scheme proposed and even if you do
users who are used to "pkg('load',<package>)" on one system would have
to get used to whatever means debian proposes to replace it.

This is why I much prefer the inclusion of an on_uninstall.m in the
package in the dpkg post-install, which throws an error if the user
tries to uninstall a package with opkg. Then the debain package is just
a thin wrapper to an octave package.

> 
> * David Bateman <David.Bateman at motorola.com> [2007-05-11 10:31]:
> 
>> Thomas Weber wrote:
>>> I'm aware of the meaning of the autoload flag. But in the current state of
>>> affairs, opkg won't be used for installing and managing the packages[1].
>>> The reason is a Highlander problem ("There Can Be Only One"): in this
>>> case, there can be only one package manager.
>> How does the debian package of R handle this? In any case unfortunately
>> there is not a one to one mapping of opkg to dpkg, as opkg handles the
>> issues of loading and unloading both manually and automatically packages
>> from the path during the runtime of Octave.
> 
> R has a different mechanism for loading libraries (or "modules", or
> "packages").  There is a command called "library" that actually put all the
> definitions for a given library into the current namespace.  In other words,
> a package must be explicitly loaded by the user if she wants to use it.
> 
> I hope this answers your question.
> 

Isn't there an automatic install process from CRAN? The same for Perl
from CPAN? Debian must live with these secondary package managers as
well. So my question was how does it?

D.