[Fedora-packaging] Octave package standard

[Orion Poplawski]

Orion Poplawski wrote:
> Toshio Kuratomi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Orion Poplawski wrote:
>>>
>>> - Currently octave uses the /usr/libexec tree to install the .oct files.
>>>  These are really shared libraries.  It does use an arch/api versioned
>>> directory, e.g.:
>>>
>>> /usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/
>>>
>>> Some other package files (PKG_ADD/PKG_DEL) get added there too.
>>>
>> This is the only part that needs more clarification to me.  If the .oct
>> files are really shared libraries it seems that they belong in
>> %{_libdir}.  libexec is more useful for binaries that shouldn't be
>> multilib like helper programs that are invoked by other programs on the
>> system and need to match arch with the invoking program for them to work
>> correctly.
> 
> Well, it would be trivial to change /usr/libexec to /usr/lib.  Multi-lib 
> is then handled by the arch string farther down.  Similar to java in 
> /usr/lib/jvm/java/jre/lib/amd64/.  Using %{_libdir} would be harder and 
> I'm not sure for what gain.  These are all dlopen libraries only for 
> octave so as long as it knows where to go, that's okay.
> 
> I also just updated the noarch spec to install from the source tarball 
> directly.  The package install script simply unpacks that tarball into 
> the temp directory then.  This assumes that nothing in the source needs 
> patching.
> 

Any final thoughts on this?  I'd like to get this decided before a final 
release of octave 3.0 is made (soon now).  Personally, I'd like to leave 
it as libexec since we may need to put some arch dependent executables 
there too.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com