Description of problem: Trying to run gnutls-2.4.2-2.fc10 with libgcypt-1.4.0-3 results in a runtime error like this: svn: relocation error: /usr/lib64/libgnutls.so.26: symbol gcry_cipher_setkey, version GCRYPT_1.2 not defined in file libgcrypt.so.11 with link time reference Updating to libgcrypt-1.4.2-2.fc10 resolves the problem. Version-Release number of selected component (if applicable): 2.4.2-2.fc10
But we have libgcrypt-1.4.3 in Fedora 10 prereleases and Rawhide. So I don't understand what is the problem.
The problem is that this sort of relationship is exactly what dependencies are for. Maintaining correct dependencies maintains the correctness of the spec file and the resiliency of the package. It ensures that updates that may not fall neatly into the categories you've envisioned can still succeed. What exactly is the argument against reflecting this dependency in the spec file?
Unfortunately this would have to be fixed by moving the gcry_cipher_setkey to a new symbol version. We cannot do that. And hardcoding the dependency on libgcrypt >=1.4.2 would not be correct either.
Pardon my ignorance, but why wouldn't "Requires: libgcrypt >= 1.4.2" be correct?
Because if you compile it against libgcrypt-1.4.0 or whatever it will compile OK and not require libgcrypt >= 1.4.2 (the gcry_cipher_setkey() was changed from macro to function in libgcrypt-1.4.2).
Then couple it with BuildRequires: libgrypt-devel >= 1.4.2. It may be ugly, but it's less ugly than simply having this dependency go undocumented and unenforced.