I'm currently working with octave upstream to get their new package management system in line with Fedora so that we can easily build RPMs with it. I'd like to get a Fedora package standard configured and approved at the same time. I've put a draft on the wiki at:
http://fedoraproject.org/wiki/PackagingDrafts/Octave
Some further information:
- 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.
- Currently the entire octave forge collection is part of the octave-forge package. I will releasing this for F8, with the understanding that this will be replaced by individual packages later. The octave forge package will have provides like:
Provides: octave-gsl = 1.0.1
to try to provide a better upgrade path. We may want to keep the octave-forge as a meta package that pulls in the others. Let me know if this doesn't seem correct.
- DISTPKG (%{octave_distpkg}) is a flag that this is being built by a package manager. The contents get inserted into an informational message, but otherwise does not mean much.
Orion Poplawski wrote:
I'm currently working with octave upstream to get their new package management system in line with Fedora so that we can easily build RPMs with it. I'd like to get a Fedora package standard configured and approved at the same time. I've put a draft on the wiki at:
Looks like a winner to me, bonus points for engaging upstream.
-- Rex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Orion Poplawski wrote:
I'm currently working with octave upstream to get their new package management system in line with Fedora so that we can easily build RPMs with it. I'd like to get a Fedora package standard configured and approved at the same time. I've put a draft on the wiki at:
http://fedoraproject.org/wiki/PackagingDrafts/Octave
Some further information:
- 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.
- -Toshio
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.
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 wrote:
Toshio Kuratomi wrote:
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/.
I'm ok with it either way.
Using %{_libdir} would be harder and I'm not sure for what gain.
*nod*, changing your proposal to try to use %{_libdir} may well be much pain for little payoff, so I personally wouldn't consider it a blocker.
-- Rex
packaging@lists.fedoraproject.org
-
Orion Poplawski -
Rex Dieter -
Toshio Kuratomi