octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OctavePackaging


From: David Bateman
Subject: Re: OctavePackaging
Date: Fri, 11 May 2007 10:31:18 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Thomas Weber wrote:
> Hi, 
>
> after writing most of this mail, I realized that dealing with two package 
> managers in an e-mail brings my language skills to a limit. So for the rest 
> of this text, dpkg is the Debian package manager, while opkg is the Octave 
> package manager. 
>
> David, if you don't mind, you can resend your original mail to our 
> development 
> list (or to the Octave maintainers list, if you think that's more 
> appropriate). I'll then resend my answer there as well, so others can 
> comment. 
>   
I thought my comment was fairly simple, rather than something that would
bring up all of the packaging issues of octave-forge in Debian. So I've
brought the discussion on to maintainers.

> Am Freitag, 11. Mai 2007 00:56:46 schrieb David Bateman:
>   
>> I just re-read the wiki page on wiki.debian.org, and there is some
>> discussion of ignoring the "autoload" flag in the package DESCRIPTION
>> files. This is a really bad idea, and not just for clutter in the
>> available functions. Firstly note the autoload flag in te DESCRIPTION
>> file has nothing to do with the "autoload" command in octave. The
>> autoload in the DESCRIPTION file allows the pkg system to run "pkg load
>> <package>" on all packages so marker when octave starts.
>>     
>
> 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.

> opkg should *not* be able to uninstall a deb-package without dpkg being aware 
> of it. Otherwise, there's not a single chance of correct dependency handling 
> (dpkg still thinks the package is there while in fact it is uninstalled). 
> This not only covers Octave packages: if a certain package requires external 
> libraries, dpkg will happily install them with the package.
>
> Now, one could argue that the root user could delete the files by hand; but I 
> think the chance of doing this by accident is far lower than making an error 
> with the package manager. 
>   
Only root can do the "pkg uninstall <package>" in octave as well.

>
>   
>> Now as pointed out on multi-user systems some users want some functions,
>> and other users others. Even at sometimes one user wants a different set
>> of files. Particularly bad packages in this respect are the TSA and NAN
>> packages that change the behavior of basic octave functions like cumsum
>> to try NAN as missing data, for example. Such packages should only be
>> loaded when the user needs them and not otherwise, with the "pkg load
>> nan" and "pkg unload nan" commands.
>>     
>
> 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.
> Hm, maybe we should introduce a removal functionality that removes packages 
> from the loadpath. I'll think about this.
>
>   
Why bother. Its also inconsistent with other users of Octave and will
cause issues for people using Octave on debian or on another system, or
even on Debian with some packages installed via dpkg and some via opkg.

Instead, keep the octave packaging system as is and make dpkg add a
script in a file called on_uninstall.m in the package that throws an
error in the dpkg post install stage. Something like

function on_ininstall (desc)
  error ("Can not uninstall package %s installed by the debian package
manager", desc.name);
endfunction


in on_uninstall.m will be sufficient. At the moment this will cause only
a warning in the pkg as the code handling this is

    if (exist (fullfile (desc.dir, "packinfo", "on_uninstall.m"), "file"))
      try
    wd = pwd ();
    cd (fullfile(desc.dir, "packinfo"));
    on_uninstall (desc);
    cd (wd);
      catch
    ## XXX: Should this rather be an error?
    warning ("the 'on_uninstall' script retsurned the following error: %s",
         lasterr ());
    cd (wd);
      end_try_catch
    endif

However, if we turn the warning into "rethrow(lasterror())" or simply
remove the try/catch block, then the user will not be able to uninstall
packages installed by dpkg with the octave package manager. They will
continue to be able to uninstalled packages installed by opkg. Then
debian can use all of the functionality of the octave package manager
(including conditional autoloading) while still enforcing that the
packages installed by dpkg are only uninstalled by dpkg... This is a
minor change to pkg.

Now for the architecture dependent versus architecture independent
stuff, there is nothing to stop the package manager from being modified
to have two directories..  For this to make sense I suppose the
architecture dependent directories should be named for the architecture
in some manner so that we can have multi-architecture support in a
single installation. Though perhaps in the context of Octave that does
make sense as the octave_config_info ("exec_prefix") (which determines
where the packages are installed system wide) will be different on an
architecture by architecture basis. In fact the architecture dependent
stuff is more of a problem with user installed packages in their home
directories as the home directory might be a network disk available on
multiple systems. So the architecture dependent issue should be handled
in opkg itself.

The simplest would be to have an architecture dependent directory as a
sub-directory of the main opkg package directory so the package
structure would look like

<package>/
<package>/<Arch>/
<package>/packinfo/
<package>/doc/
<package>/bin/

The value of <Arch> would be constructed in opkg as

unm = uname();
Arch = [unm.sysname,"-",unm.machine];

One issue I then see with the above is if Debian's dpkg is in control of
removing packages it installed, then you have to decide how to handle
the file "<exec_prefix>/share/octave/octave_packages". This is an Octave
saved file with a structure in it containing information about the
installed packages.

On install of the package by dpkg you can use opkg to install as I did
for the SRPMs I sent (and can be build in o-f with "make srpms") and
this structure will be handled automatically. However, the dpkg
pre-uninstall stage will need to remove the on_uninstall.m file before
using opkg for the uninstall. The other option is to have a debian
uninstall script that knows about the format of octave_packages and
removes the entry for the uninstalled package. I prefer largely the
first as if opkg evolves and changes the file format of octave_packages,
then you'll have to adapt your scripts.

> Just a thought: if two octave packages have a file with the same name, how 
> can 
> I influence which one is used?
>   
This is exactly the issue we have with the NaN and TSA packages that
overload certain Octave functionality. Each package is loaded to the
front of the user path (but "." is always in front) as it is treated by
"pkg load". With pkg("load","auto") that is in a PKG_ADD in pkg.m the
order of installation depends on the order returned by
pkg:installed_packages. Unfortunately this depends on the order in which
they are saved to the octave_packages file. You might force the issue by
fixing the order of loading the packages in the site-wide octaverc file
by individually loading the packages.

>
> [1] That's the idea which I'm working currently on.
> [2] This is not just an exercise in scripting for me, but required by the 
> Linux FHS. FHS compliance (or rather failing it) is a release blocker for the 
> respective package. I don't know how other distributions handle this.
>
>       Thomas
>   

Regards
David


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



reply via email to

[Prev in Thread] Current Thread [Next in Thread]