5

I try to make a package of a program which is linked to such library (output from ldd):

libwx_baseu-2.8.so.0 => /usr/lib64/wx-2.8-wxcontainer/libwx_baseu-2.8.so.0

Pretty straightforward, right? But when I make a package of this program (with rpmbuild) and then try to install it, rpm complains about missing library (this one above):

error: Failed dependencies:

    libwx_baseu-2.8.so.0()(64bit) 
    libwx_baseu-2.8.so.0(WXU_2.8)(64bit)

My guess is, rpmbuild set the dependency for the main lib directory, i.e. /usr/lib64.

Question -- how to fix this issue (ok, one would be forced install, but I would like to avoid it)? I.e. how to build rpm so the dependencies would set for the wx-2.8-wxcontainer subdirectory (for this library)?

openSUSE 11.4, if this matters.

Edit

I can install such package with --nodeps which forces installation, and after that install program works perfectly. So clearly, rpm or rpmbuild has issues, not the system itself.

|improve this question|||||
2

I think this is limitation or bug in current rpm/rpmbuild versions. I reported this issue so I think in a way question is answered:

https://bugzilla.novell.com/show_bug.cgi?id=697943

You always have to install wx rpms in pairs — one with real library, the other package which simply says "the library was installed".

  • libwx_baseu_net-2_8-0-wxcontainer-2.8.12-3.1.x86_64
  • libwx_baseu_net-2_8-0-compat-lib-wxcontainer-2.8.12-3.1.x86_64

Without the second rpm, the package manager and/or dependent application would not know that the corresponding wx library is present at all.

|improve this answer|||||
1

I think, that you are mixing files and packages.

The fact that the library exists on your disk doesn't mean that it can be used to resolve a dependency. For that, there has to be a package that provides this library.

On the other hand, for dependency resolving, the file actually doesn't even have to exist. Only the fact, that some installed package provides it should be enough.

|improve this answer|||||
  • 2
    Rpm does use file names as dependencies (unlike dpkg), so I don't think macias's question actually indicates a mix-up. – Gilles 'SO- stop being evil' May 30 '11 at 21:22
  • "The fact that the library exists on your disk doesn't mean that it can be used to resolve a dependency. For that, there has to be a package that provides this library." Not true -- you can set dependency upon package or raw file. I have (because rpmbuild did it) only dependencies for raw files. "On the other hand, for dependency resolving, the file actually doesn't even have to exist. Only the fact, that some installed package provides it should be enough." True, but it is not my case. – greenoldman May 31 '11 at 4:52
1

Add a Provides field into the spec file header, e.g.
Provides: lib_missing_complaint.so()(64bit)

This doesn't work when the dependency starts with e.g. ../
In that case use
AutoReq: no

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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