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.