Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
    
I know this is very old; but is there a good solution now for this? I am making an RPM which has java-1.6.0-openjdk in Requires: line; but with java7; I would like to support java-1.7.0-openjdk as well but could not figure out a good way to put either of those two in Requires: –  vpram86 Aug 22 '13 at 8:48

3 Answers 3

This kind of behaviour is already done by several packages, for example mail transport agents. Those virtual packages provide your system a way to know if a capability they need is already provided by some other program.

See if virtual packages example in rpm.org helps you.

share|improve this answer
    
Thanks. I don't think virtual packages will solve my specific problem here, but I agree they are very useful. In my case I don't want to require some common feature provided by both foo-bar and bar-foo, and since I don't control the packaging of foo-bar I can't just make them both provide support-for-mypackage. If I controlled the packaging of both alternate prerequisites then indeed a shared virtual package would be a great solution. –  Kevin Frost Aug 9 '11 at 13:30

Two possibilities:

If the part of foo-bar and bar-foo you use is a common file you can just Require /path/to/file (I think so; my testing was limited).

Your situation is similar to optional dependencies. The way they are handled is to have a X-common package and then have a X-foo-bar package that requires foo-bar and an X-bar-foo package that requires bar-foo.

share|improve this answer
    
There are no common files, unfortunately. That would be a cool trick if there were, though also potentially dangerous: some future version of foo-bar could move its files around (I only control bar-foo here). Optional dependencies are interesting but not quite what I need, since I really do need either foo-bar or bar-foo; the only thing optional is the choice of which. Thanks for replying. –  Kevin Frost Aug 10 '11 at 17:15

Will it work for you to have your package bar-foo provide the virtual package foo-bar?

You can then just make your burp-baz package require foo-bar.


If doing the above feels skeezy (it probably is) you may need to create two versions of your RPM, one depending on foo-bar and the other depending on bar-foo.

share|improve this answer
    
Tempting, but dangerous: something else, which really does need foo-bar, would then break if it thought bar-foo was providing something it really wasn't. The sticking point is that for my package I need either of the prerequisites but not both; but any other package might really need just one of them. And I can't just require both either, since there are real cases where only one or the other will be available. –  Kevin Frost Aug 9 '11 at 18:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.