Naftuli Kay
Naftuli Kay

Reputation: 91790

Should I still declare Requires dependencies for other shared objects?

One of the interesting features of RPM is that it will look at shared objects, find out what they're linked against, find out what packages provide those linked shared libraries, and automatically install those dependent libraries as part of the installation of the compiled shared library.

If libnaftuli is linked against libbz2, for instance, rpm-build will specify the dependency in the libnaftuli RPM without my having to declare it in my .spec file.

Should I still declare those dependencies in my spec file then? I suppose that I should declare ambiguous dependencies, but otherwise should I still manually figure out what my libraries link against and specify their requires clauses, or just let rpm-build be smart?

Upvotes: 1

Views: 593

Answers (2)

Thomas Dickey
Thomas Dickey

Reputation: 54583

The automatic dependencies added by rpmbuild are helpful, but they do not do everything. Explicit Requires tags can do these extra things:

  • tell rpm that it is okay to install your package with specific versions (including a range of versions) of a given dependency.
  • tell rpm that the package depends upon a virtual package, e.g., a package which provides the "same" functionality but under different names (such as saying any Java package).

Further reading:

Upvotes: 1

Etan Reisner
Etan Reisner

Reputation: 81022

If you require some other package solely because of a library requirement that rpm figures out for you then no there isn't really any reason to list the package as a requirement yourself manually.

If, however, you depend on that package for some other reason (non-library file, etc.) or have specific versioning requirements on the package (which library versioning should generally handle for you so you shouldn't) then adding it yourself makes sense.

Any other packages you have requirements on, that rpm doesn't pick up, should obviously be listed explicitly.

Upvotes: 1

Related Questions