Re: 2.9.11?

[David Bateman]

Rafael Laboissiere wrote:
> * Thomas Weber <address@hidden> [2007-04-19 09:21]:
> 
>> Am Donnerstag, 19. April 2007 00:16 schrieb David Bateman:
>>> The biggest remaining issue for a testing release for me is the package
>>> manager. Till debian, fedora and MSVC builds sign off on the package
>>> manager I don't think 2.9.11 will be really considered as a testing
>>> release by the distributions..So it might be nice to check on the
>>> progress of the use of the package manager for these three, to at least
>>> avoid any hurried 2.9.12 release if possible.
>> A new Octave release is not a problem for Debian. We will currently stay 
>> with 
>> 2.9.9 in the testing part of the distribution, until we've figured out how 
>> to 
>> integrate the Octave package manager [OPM] with the distribution package 
>> manager (or, more precisely: how to use the OPM for creating the packages).
>>
>> Some ideas are available at 
>> http://wiki.debian.org/OctavePackaging
> 
> Just to complement Thomas' info: the above wiki page is open to everybody,
> not only to Debian Developers.  The ideas being discussed there are general
> enough to be also useful for the RPM-based Linux distributions.  Everybody
> is encouraged to contribute by editing the page (you will need to create an
> account on wiki.debian.org before doing that).
> 

Rafael/Thomas,

I had a look at your wiki, and yes you do need to manipulate the global
and local lists to make a binary package. I tried to think ahead of the
packaging issues and included an RPM example building process in
octave-forge itself. I doubt it will work correctly under debian, but if
you do "make srpms" under octave-forge it will build a set of source
RPMS that could be used as an example of what I'm currently using on my
system. Sorry I couldn't do the same for deb files as I don't understand
debian packaging.

The %prep and %build sections of the SPEC file for one of the packages
looks like

%prep
rm -fr signal-1.0.0
mkdir signal-1.0.0
cd signal-1.0.0
cp %{_sourcedir}/signal-1.0.0.tar.gz .
chmod a+r signal-1.0.0.tar.gz
mkdir -p install/signal
mkdir install/signal/inst

%build
cd signal-1.0.0
HOME=`pwd` %{octave} -H -q --no-site-file --eval
"pkg('prefix',[pwd(),'/install'
]);pkg('local_list',[pwd(),'/install/.octave_packages']);pkg('global_list',[pwd(
),'/install/.octave_packages']);pkg('install','signal-1.0.0.tar.gz')"
cd install
mv signal-1.0.0/packinfo/* signal
rm -rf signal-1.0.0/packinfo
if [ -d signal-1.0.0/doc ]; then mv signal-1.0.0/doc signal; fi
if [ -d signal-1.0.0/bin ]; then mv signal-1.0.0/bin signal; fi
if [ -e signal-1.0.0/PKG_ADD ]; then mv signal-1.0.0/PKG_ADD signal; fi
if [ -e signal-1.0.0/PKG_DEL ]; then mv signal-1.0.0/PKG_DEL signal; fi
mv signal-1.0.0/* signal/inst
rm -fr signal-1.0.0.tar.gz
tar czf ../%{builtpackage} signal

where %{builtpackage} is now a binary package that can later be
installed by the package manager. The section of the SPEC control this is

%install
cd signal-1.0.0
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_datadir}
cp %{builtpackage} %{buildroot}%{_datadir}

%post
%{octave} -H -q --no-site-file --eval
"warning('off','all');pkg('install','%{_datadir}/%{builtpackage}')"
rm %{_datadir}/%{builtpackage}

So to build the binary package out of the normal directories, you must

1) Set the HOME variable to the build directory
2) set both the local_list and the global_list variables (to be sure) to
 point to a package file in the build directory that will later be removed
3) Run the pkg install command on the source package
4) Reconstruct a package from the installed package essentially copying
everything from the install directory to the new packages /inst
directory and relocating a few other files and directories.

Note there is also a section to supply hints to building the packages on
the dependencies that the automatic SRPM build process attempts to use.
Ideally I'd like to see some sort of automatic deb build process in
octave-forge itself in a similar manner to the RPM process. Sure I know
these will almost always need manual editing, but at least having most
of the grunt work of building packages of the distributions would be a
good thing..

Cheers
David