Can one require “this OR that” package in an RPM spec file

Does anyone know how to (or whether one can) specify an alternate requirement or set of requirements in a spec file, as opposed to a single requirement?

For example, say there are two packages available, conveniently named foo-bar and bar-foo. My package requires one of these but not both, and I don't care which one is present. At runtime I use whichever is available.

So effectively I would like a way to say:

Requires: foo-bar OR bar-foo

As far as I can tell that's not possible, but I figure there are people here who know a lot more about RPM than I do, so maybe there's a way to do it.

UPDATE: I only control the packaging of bar-foo, not foo-bar, so having both provide a virtual package won't work.

UPDATE: The thing I actually need is itself a virtual package inside each of the packages. Say foo-bar provides eagle' andbar-foo provides beagleand my package works with either (or both); but other packages require eithereagleorbeagleorfoo-barorbar-foo`, and the target system can have either or both installed.

I'm currently leaning towards solving this with a %pre script that does something like:

rpm -q eagle || rpm -q beagle || echo "need eagle or beagle" && /bin/false

While I'm pretty sure that would work, it seems like a brutal circumvention of RPM's dependency tracking. For instance you'd never see my package when you asked whatrequires foo-bar or whatrequires beagle.

UPDATE: On second thought, the pain of requiring people to install foo-bar where they might not is less than the pain of circumventing RPM dependency management, at least for my situation. So unless somebody comes up with a way to properly require "this OR that" (which I think would be a great feature to have in RPM generally) then I plan to require only foo-bar and then, at runtime, if bar-foo is available I will choose between them according to whatever criteria I need.

UPDATE: another idea, which would also be cheating RPM but might get things into the right state. Maybe I could, in %post, fiddle with RPM's database directly. Thus %pre could protect me from an invalid install, and %post would retroactively tell RPM that I require either foo-bar or bar-foo or both, depending on what's there when I install.

Thanks for the suggestions!