On Wed, 2006-11-22 at 14:50 -0700, Orion Poplawski wrote:

octave defines an API version in:

octave-2.9.9/src/version.h: #define OCTAVE_API_VERSION "api-v22"

Modules compiled against one version will not load in another. I'd like to get this put into the rpms like:

Provides: octave(api) = api-v22

This can be done automatically on the module side with something like:

Requires: octave(api) = %(octave-config -p API_VERSION)

But, how to extract this automatically from src/version.h in the octave package itself?

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.

For a concrete example, see %{apiver} in the FE vdr package.

...

...

...

...

"OP" == Orion Poplawski orion@cora.nwra.com writes:

OP> I went with octave(%{octave_api}) rather than octave(api) = OP> {octave_api} because I was getting errors when starting to build a OP> package in mock that octave(api) was not being set to anything OP> (during the buildroot setup phase - octave-config is unavailable OP> there). If someone can point me around that, that would be great.

You just have to make sure it's defined to something like 0 so that the specfile is syntactically correct. Usually this is done with something like:

%{!?octave_api: %define octave_api %(octave-config -p API_VERSION || 0)}

assuming that even parses.

- J<

On Mon, 2006-11-27 at 16:09 -0700, Orion Poplawski wrote:

I went with octave(%{octave_api}) rather than octave(api) = %{octave_api}

The potential problem with that is that it has severely limited possibilities of versioned dependencies - only an exact match works, you can't do eg. ">=" with it. You know better than me whether that's actually ever likely to become a problem in this case.

In the VDR case, I'm using the API version like "Provides: vdr(abi) = ..." and "Provides: vdr-devel(api) = ..." in the main and -devel packages, and "BuildRequires: vdr-devel(api) >= ..." and "Requires: vdr(abi) = ..." in plugin packages.

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.

Like tibbs said, just make sure it parses correctly even if octave is not available. The %{apiver} definition in vdr-subtitles and vdr-osdteletext packages contain one example way to do it.