39

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!

Kevin Frost
  • 491

5 Answers5

19

This is now possible as of RPM 4.13.

https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html

It can be just simple as: Requires: (pkgA >= 3.2 or pkgB)

Graham Leggett
  • 287
  • 3
  • 15
carlwgeorge
  • 567
9

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.

dimir
  • 115
Janne Pikkarainen
  • 32,512
5

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.

Mark Wagner
  • 18,428
0

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.
MikeyB
  • 40,079
-2

Non-determinism in automated systems (which is either dependency management or the machines that use RPMs) is a really bad thing. You WANT it to fail on a this-or-that situation, as failing is still not as bad as an unexpected outcome.

To solve the issue, maybe have the package you DO control %provide the main tokens that the immutable package also happens to %provide and which your other software %depends; then have your package %obsoletes the immutable one. Especially if it's already in place, you may get it winning out over the other install.

Packaging and proper dependency and install operations is tricky work. The goal - reliable, repeatable, auditable installs - is so valuable that you may realize the gains of getting it right.

Dependency hell is self-inflicted. No exceptions

user2066657
  • 348