octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with build Fedora RPMs of octave packages


From: David Bateman
Subject: Re: Issues with build Fedora RPMs of octave packages
Date: Thu, 20 Sep 2007 18:01:20 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Orion Poplawski wrote:
>
> I'm interested in making it easy to produce RPMs of octave packages
> for Fedora.
>
> Starting with the rpm_template.in found in octave forge, I've got the
> following basic build/install instructions:
>
> configure
> make
> make install DESTDIR=$RPM_BUILD_ROOT DISTPKG=redhat
>
> The main problem with this is that this use octave pkg install and
> everything ends up under /usr/share/octave/packages/%name-%version/
> including binary architecture dependent files.  This is not acceptable
> in Fedora (and other distributions) and breaks the FHS.
The binary architecture dependent files are under a separate directory in


arch = strcat (octave_config_info("canonical_host_type"), ...
                 "-", octave_config_info("api_version"));

/usr/share/octave/packages/%name-%version/%arch

Where should they be to meet the FHS? The only constraint I see on their
placement is that it would be better to have each packages architecture
dependent files in a separate directory. This for the PKG_ADD command
issue below.

>
> I have made some hacks to split the .oct files into
> LOCALAPIOCTFILEDIR, but this bring up an issue with the recommended
> format of PKG_ADD:
>
> autoload ("airy_Ai_deriv", fullfile (fileparts (mfilename
> ("fullpath")), "gsl_sf.oct"));
>
> Which expects the PKG_ADD file to be in the same directory as the .oct
> files, which is not the case with the split.
Unfortunately this the only way that will be guaranteed to work. There
was some discussion of this on the maintainers list in the with
something like

autoload ("airy_Ai_deriv", which("gsl_sf"));

being suggested. However the issue with this is that if there happens to
be another function by the same name on the users path as gsl_sf, but
before gsl_sf, then it will be selected for the autoload first. This
means that the autoload will be dependent on the users path. This is not
acceptable. This is also why autoload now requires absolute paths..

An alternative might be to modify the autoload such that

autoload ("airy_Ai_deriv", "gsl_sf")

looks in the same directory as the PKG_ADD file that contains it first
and only afterwards looks in the users path. This fixes the issue of the
user path dependency on autoload but still means the PKG_ADD files have
to be in the same directory as gsl_sf.oct..

Other suggestions..

>
> I'd appreciate some discussion to see what would be workable to
> support making RPMs of octave packages.
>
> Thanks!
>
Cheers
D.

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

The information contained in this communication has been classified as: 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]