Ville Skyttä wrote:
One KISS way to handle this is to just hardcode the API version in a
macro in the octave specfile, bump it between package versions as
appropriate, and add a test in %check which will cause the octave
package build to fail if you forgot to bring the hardcoded value up to
date with the sources when updating the package.
How does this sound:
octave.spec:
@@ -1,3 +1,6 @@
+# From src/version.h:#define OCTAVE_API_VERSION
+%define octave_api api-v22
+
Name: octave
Version: 2.9.9
Release: 1%{?dist}
@@ -18,6 +21,7 @@
BuildRequires: readline-devel glibc-devel fftw-devel gperf ghostscript
BuildRequires: ufsparse-devel glpk-devel gnuplot desktop-file-utils
BuildRoot:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Provides: octave(%{octave_api})
%description
@@ -49,6 +53,12 @@
%prep
%setup -q
+# Check that octave_api is set correctly
+if ! grep -q '^#define OCTAVE_API_VERSION "%{octave_api}"' src/version.h
+then
+ echo "octave_api variable in spec does not match src/version.h"
+ exit 1
+fi
%build
Then in an octave module:
%{!?octave_api: %define octave_api %(octave-config -p API_VERSION)}
Requires: octave(%{octave_api})
I went with octave(%{octave_api}) rather than octave(api) =
%{octave_api} because I was getting errors when starting to build a
package in mock that octave(api) was not being set to anything (during
the buildroot setup phase - octave-config is unavailable there). If
someone can point me around that, that would be great.
--
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
