Re: PKG wishlist

[David Bateman]

Søren Hauberg wrote:
> Hi,
>   First I must apologize for this late reply, but things have been
> really crazy in the real life.

Hey, I had three weeks out recently :-)

> 
> fre, 25 08 2006 kl. 17:20 +0200, skrev David Bateman:
>> Can and should we change the package manager to enforce that the name of
>> the package corresponds to the file name? This would be easy to enforce
>> in pkg.m, and not more harder in octave-forge to build the package from
>> DESCRIPTON(name:) rather than the directory name.
> This makes perfect sense to me, and the code looks good. Thanks for
> doing this.

Except that there is a problem with the whole concept of bundles as you
recently introduced. I've just tripped over this while trying to write
code to test a package and its dependencies within octave-forge. If
there is more than one package (as indicated by more than one
subdirectory in the archive) then there is no way for the archive name
to correspond to the name of all of the packages.

The way I see of dealing with this is enforcing that a package can only
have a single sub-directory. A bundle would then be another archive,
that is an archive of packages, and not the sub-directories contained in
the packages. Should we treat bundles of such bundles? If you are ok
with this then I'll take a go at implementing it.

>> 2) If for some reason the directory for the package that is created is
>> empty, then remove the package. This allows system specific packages (eg
>> MacOSX) to attempt to be installed on other architecture fail gracefully.
> Seems kinda like a hack to me, but since I don't have a better solution,
> I can't really complain :-)

The other way of dealing with it is just don't install such packages.
This however, puts the responsibility on the OS packager (ie rpm, deb,
etc) to be responsible for removing system specific packages from the
build. This change just allows the Octave-forge packager to make their
life easier (if they choose to).

> 
> Once again, I apologize for being so late in my reply. And I must say
> thank you for working on these issues. I just hope the code isn't to
> hard to work on... :-)
> 

No its ok, but tell me if you want to work on pkg and I'll stay away for
a while..

In any case where octave-forge is at now, after the stuff I've committed
is that all but four packages are converted these being

1) extra/graceplot, as I haven't dealt with the issue of the alternative
paths in this package, and haven't tested any of the initial packaging
I've done for graceplot
2) extra/perl, as this is a perl CPAN package and it makes no sense to
have it in the octave package manager
3) extra/tk_octave as there are some really quite complex install
issues, such as having a version of octave built with pthreads that I
can't see how to deal with in the package manager, though initial
packaging is done. Paul do you want to deal with this?
4) nonfree/gpc as there is an issue with how this package uses automake
and the missing files flagged by automake and how to deal with them

In any case I went on with the rest of the changes needed in
octave-forge, trying to replace the "make check" command and the start
of octave-forge bundles. The make check code basically works except for
the above issue with bundles (which in fact I use everywhere in the
checking code to simplify the dependency stuff)

Things I think still need doing

1) Fix the bundles issue in pkg
2) Complete the README in the o-f bundles, and add some post-install and
 pre-uninstall m-files to the bundles so that the RPM, DEB packages and
create a binaries package (everything in <pkg>/inst) and use octave
itself to deal with the install and the update of the octave_packages
files. This will probably also need code like the "make check" stuff to
allow create of the binaries package in a sandbox.
3) RPM and Windows directories need to be updated to reflect the changes
4) Automatic webpage creation for each package from the description file
with inclusion of any html docs that are found in the package
5) Make sure that the mkindex script still works
6) Update all of the o-f docs to reflect the changes
7) clean out some of the unnecessary stuff from o-f (??)
8) Probably something else I forgot.

Want to tackle some of the points above? Octave-forge is really in a
state far from a release at the moment...

D.