Re: PKG wishlist

[Søren Hauberg]

ons, 30 08 2006 kl. 23:40 +0200, skrev David Bateman:
> > 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.
Doh! You're right. At first I simply wanted a bundle to be an archive of
packages, but I thought it would be to much work to implement. This is
why I simply used subdirs in the archive.
But what about the problem that made you enforce packagename==filename?
What happens if a bundle doesn't include all it's dependecies? Will that
give you any problems?

> >> 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).
We could introduce an optional OS keyword in the DESCRIPTION file. If
the DESCRIPTION file contains
  Operation System: MacOS X
then RPM builders could simply grep the DESCRIPTION files to see which
they should build.

> > 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)
Wow, you've been a busy worker :-)

> Things I think still need doing
> 
> 1) Fix the bundles issue in pkg
If the code doesn't get to complex, I think having a bundle be an
archive of archives is just fine.

> 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.
Perhaps we should have a
  pkg build <package name>
command that compiles the .cc files in the package, but doesn't install
the package. I don't know anything about rpm/deb but I assume that
having a bunch of files that just needs to be copied is fairly easy to
package.

> 4) Automatic webpage creation for each package from the description file
> with inclusion of any html docs that are found in the package
I think I have some code for this somewhere -- I'll browse my archives.

> 7) clean out some of the unnecessary stuff from o-f (??)
But this is a fairly small issue, right?

> Want to tackle some of the points above? Octave-forge is really in a
> state far from a release at the moment...
Sure, I think I can find some time over the weekend. Is there anywere I
should focus? I don't know about rpm/deb creation, but if you want I can
read up on this...

Søren