On Tue, Aug 30, 2005 at 01:56:48PM -0700, jeff stern wrote: > Peter C. Norton wrote: > >On Tue, Aug 30, 2005 at 01:41:07PM -0700, jeff stern wrote: > > > >>but this is exactly the problem. the .spec file never said that the > >>php-interbase sub-package *requires* libgds.so.. but it generated it > >>anyway as a 'requires'.. so apparently, rpm's automatic > >>dependency-checking *does* check things that are not in rpms..? > > > > > >It does, but it doesn't touch that library. When your system has a > >library that a file in your package requires it'll get found and > >listed as a dependancy unless you tailor your dependancies manually or > >semi-manually. > > > >When rpmbuild does its auto dependancy solving on binaries, it is just > >running "ldd" to find out what libraries all of the executeables in > >the package needs. > > okay, thanks, this is what i figured. but then it just leads back to my > original question: why can't rpm -i php-interbase find libgds.so, when > in fact, libgds.so IS on my system (since it's the same system i > actually compiled the php-interbase rpm on in the first place)? Because it's not ever "finding" anything on the filesystem. ldd picks up the hint int the binary that it needs a library. rpm checks it's database to see if something that has that symbol is in its database. If it doesn't match, then rpm can't help you. If you want interbase to be an optional component, then you have to either completely disable the dependancy check, or get the output of the dependancy checker and mangle it's output so that this is not taken into consideration. This is done by /usr/lib/rpm/rpmdeps. So you can get: $ /usr/lib/rpm/rpmdeps -R /bin/ls libacl.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.2.3) libc.so.6(GLIBC_2.3) libtermcap.so.2 To override this, you can set your private .rpmmacros to emulate this setup from a default /usr/lib/rpm/macros: # # Path to scripts to autogenerate package dependencies, # # Note: Used iff _use_internal_dependency_generator is zero. #%__find_provides /usr/lib/rpm/rpmdeps --provides #%__find_requires /usr/lib/rpm/rpmdeps --requires %__find_provides /usr/lib/rpm/find-provides %__find_requires /usr/lib/rpm/find-requires #%__find_conflicts ??? #%__find_obsoletes ??? So if you define %_use_internal-dependancy_generater 0 you can %define __find_requires to a script that will rpm something like this: #!/bin/sh /usr/lib/rpm/rpmdeps --requires | grep -v libgds.so You probably want to set __find_provides as well, or else packages that depend on yours will not know what it's got. Anyway, try thinking of rpm as less of a holistic tool and more of a specialized database that runs commands based on its state and its contents, and you'll find yourself less confused. Rpm, and therefore yum as well, only know about what's in the database -Peter P.S. my examples are from brutally butchered memories of how to package perl. I don't have to mess with that anymore, so you may have to tweak my example. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.
