/usr/lib/librpm.la contains: dependency_libs=' -L/usr/src/build/515221-i386/install/usr/lib -L/usr/lib /usr/lib/librpmdb.la -L/usr/src/build/515221-i386/BUILD/rpm-4.4.1/zlib -L/usr/local/lib -L/usr/kerberos/lib /usr/lib/libsqlite3.la -lelf /usr/lib/librpmio.la /usr/lib/libbeecrypt.la -lm /usr/lib/libneon.la -lssl -lcrypto -ldl -lz -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv /usr/lib/libexpat.la -lrt -lpthread -lbz2 /usr/lib/libpopt.la -lselinux' and must therefore "Require: neon-devel, sqlite3-devel, beecrypt-devel" (etc?) for presence of those .la files, otherwise libtool fails when linking against librpm.la.
those -L's are all pretty dodgy too FWIW, not an rpm-specific issue of course...
The dependencies are tracked through BuildRequires: already. Without explicit convention (or definite fault) it is unclear whether the Requires: in rpm-devel are needed as well as the BuildRequires:. -L paths are dodgy yes, but needed (at least the very first one) to insure that libtool links against the newly built libraries. *** This bug has been marked as a duplicate of 116891 ***
BuildRequires are not sufficient: Linking against librpm using libtool fails if sqlite3-devel is not installed. libtool attempts to resolve the dependencies listed and fails if any listed .la files are missing. This is an easily observable fact which I just observed in the FC4 buildroot when attempting to rebuild PHP. ergo, rpm-devel needs to Require: sqlite3-devel et al. ... grep: /usr/lib/libsqlite3.la: No such file or directory /bin/sed: can't read /usr/lib/libsqlite3.la: No such file or directory libtool: link: `/usr/lib/libsqlite3.la' is not a valid libtool archive make: *** [ext/snmp/snmp.la] Error 1
Sufficient is in the eye of the beholder. Yes better could be done. PHP needs rpm? Whatever for?
There's nothing subjective about the fact that the missing Requires: broke the PHP build. PHP needs net-snmp needs librpm.
I resist adding dependencies needlessly, not to be difficult. Yes, BuildRequires: as currently used are inadequate to tack the problem you are describing. If we are going to track -devel dependencies better, then better automation, not more manual cruft, is needed. For example, dependencies on package name, rather than on soname or file path, are implicit and subjective rather than explicit and automagically mechanically extracted. An PHP depending on rpmlib terrifies me. Why exactly is PHP depending on rpmlib.
Ah, got it. The better fix is to nuke the net-snmp dependency on rpmlib (which is a hack I did in 1998, all that is really needed is rpm -qa spew for the mib) I'll add the dependencies to rpm-devel, but I strongly believe the mannaer in which build dependencies are currently done is bogus. But that's not your problem, it's mine.
Fixed in rpm-4.4.1-0.20. Sorry for the hassle.