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@xxxxxxxxxxxxx
Boulder, CO 80301 http://www.cora.nwra.com
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
