Re: [OctDev] pkg manager

[David B. <Dav...@mo...>]

S=C3=B8ren Hauberg wrote:
>
>> First we need a build target for the packages themselves in the packag=
es/
>> directory with a temporary install directory.=20
>>    =20
> I don't understand what that means (sorry).
>  =20

Basically, main/, extra/, etc are just the repository used to create the
package tar-balls, and the code is no longer built there, but is rather
built by the package manager itself. Even if the code could be built in
these directories it is not in our interests to do so as we aren't doing
our test build in the same manner as the user will use the packages.

Better to have a Makefile in the newly created packages/ directory with
a build and test target, where the build target uses the package manager
to build all of the packages in the directory, or better still all of
the package currently built in main/, etc and not containing NOINSTALL.

>  =20
>> We need a test target to run the stand-alone and embedded test code in=
 the installation
>> directory.=20
>>    =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...
>  =20
There aren't many batch tests that are left as the embedded test code is
much more heavily used. They are basically only present for the comm,
fixed and image toolboxes. I haven't converted my test code, due to the
fact that it seemed quite complex to do it correctly (ie splitting the
tests to reside with the relevant functions. However, I suppose a quick
and dirty way to do it now that the test code allows functions, is just
to convert the existing code to a single test. I'll do this and get rid
of the batch tests.

As for the embedded tests, the admin/mktest.sh script needs to be
slightly modified as it would no longer need to worry about building a
local PKG_ADD file as the installed packages themselves would deal with
that.

>  =20
>> We need to check that the scripts in the admin/ directory
>> still work correct.=20
>>    =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 version=
s
> of octave, which isn't needed any more.
>  =20

We need to keep and check at least find_changes, get_authors,
get_contents, make_index, mkdoc, mktexi, mktests.sh, run_forge,
template.ndev and template.README. Most of the changes are probably
trivial. Though at least run_forge needs major modification to allow the
tests to be correctly run and built with a temporary package install
path. Honestly, I don't see that there is much code that allows specific
use of multiple versions of octave in these scripts.

OctRe.pm, change_va_arg.pm  and no_vr_val.pm  are no longer needed, but
were kept as examples of how to automate code changes in the future.

Equally we need to figure out what to do with the admin/RPM/ and
admin/Windows/ directories. In particular the Windows directory might
pose large problems.
>  =20
>> The top-level configure stuff is still used by the build of my
>> documentation in main/{fixed,comm}/doc, and might be used elsewhere. S=
o
>> it either needs to be kept, and largely simplified, or partially
>> duplicated in each of the package that use it for other things than th=
e
>> 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 =
as
>> well.
>>    =20
> Agreed!
>
> We also need:
> * Scripts for creating RPM and DEB packages from a package.
> * Scripts that can create web pages for each package.
>  =20
How are the webpages created automatically? Are they just the
DESCRIPTION files with links to the function helps? Do we add a
mechanism to add additional documentation. Both the comm and fixed
toolboxes have html documentation, and I believe other do as well. If
you want to automate the production of this additional documentation,
then we probably also need to specify exactly how documentation should
be added to the 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?
>  =20
The non-free distinction can be probed from the DESCRIPTION file. Though
have you thought that the package itself might be under one license but
a dependent library under another. Think of the the nonfree/gpc package,
where the gpc library is non-distributable while the octave binding are.
Maybe you need another argument in the DESCRIPTION file similar to that
in the RPM spec files to define not only the license but whether a
library is generally distributable.

As for the extra/ directory, the reason for its existence was that the
scope of the packages in this directory were supposed to be much more
limited and so the majority of users probably wouldn't want to install
them. Making this distinction makes it easier for packagers to decide
which code to build and ignore. If the deb and rpm packages are on a
package by package basis, then yes we probably don't need extras/.
However, if we have an overall tar-ball (to aid deb and RPM packagers),
then shouldn't we still help them decide what to install by making the
distinction about code that most people would or wouldn't want to
install? Maybe the extras/ directory is not the best way to do this
however with packages.

Regards
David

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

The information contained in this communication has been classified as:=20

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