Re: [OctDev] pkg manager

[H. <so...@ha...>]

tir, 22 08 2006 kl. 23:01 +0200, skrev David Bateman:
> I can't reply on list at the moment.=20
I'm also sending my answer to the list.

> But your error is that there is
> bogus main/autom4te.cache directory in main/, this is part of the
> configure process and so should only be in the head. Can you remove thi=
s
> and check for other bogus directories and try again..
Okay, I just deleted the unwanted directories and things worked.=20

> I've thought about the rest of this a little further and basically I se=
e
> that the approach this implies need a couple of extra things.=20

> First we need a build target for the packages themselves in the package=
s/
> directory with a temporary install directory.=20
I don't understand what that means (sorry).

> We need a test target to run the stand-alone and embedded test code in =
the installation
> directory.=20
Okay. This code only relies on octave and not octave-forge right? It
seems to me that the embedded code doesn't make sense to have as a
package (right?). Shouldn't we just release that as a tar-ball which
doesn't use the package manager. Perhaps I'm misunderstanding things --
I'm not very familiar with octave-forge...

> We need to check that the scripts in the admin/ directory
> still work correct.=20
How many of the scripts are actually needed? I'm under the impression
that many of the scripts were designed to handle many different versions
of octave, which isn't needed any more.

> We need to upto the developer documentation to
> reflect the new means of including a package in the octave-forge CVS,
> while also stating that the package can equally exist independently fro=
m
> octave-forge.
Yes. And we (me, I guess) need to write tutorials on actually creating
packages.

> The top-level configure stuff is still used by the build of my
> documentation in main/{fixed,comm}/doc, and might be used elsewhere. So
> it either needs to be kept, and largely simplified, or partially
> duplicated in each of the package that use it for other things than the
> pkg/src directory. I think it might be better to keep the toplevel
> configure to prevent duplication. Since if I copy it to the
> sub-directories I'd have to copy the support scripts mkdoc and mktexi a=
s
> well.
Agreed!

We also need:
* Scripts for creating RPM and DEB packages from a package.
* Scripts that can create web pages for each package.

Btw. is there a need to split octave-forge into main, extra, and
non-free anymore? Can't we simply have one main directory?

S=C3=B8ren