On 4/26/11 9:21 AM, Kurt Roeckx wrote: > >> I'm guessing a recompile of Qt will fix this. I'll give that a shot and >> see if it improves things. > There wasn't a binNMU for qt4-x11 because libqt4-network does not > depend on libssl, nor is there a build-dependency on it. So why > does it use it? To get an authoritative answer, you'll have to check with the Qt maintainers, but my guess is: Qt supports optional runtime detection of libssl and libcrypto. If found, Qt supports SSL/TLS, and if not found, it does not support SSL/TLS. By using this runtime detection, the package avoids a hard dependency on optional functionality. Packages that want qt with SSL support would simply add libssl to their dependency list.
That being said, Qt also supports explicit compile-time linking to libssl and libcrypto, which avoids issues like this one and also ensures that libqt4-network shows up as a reverse dependency for openssl. If nothing else, the runtime libraries for OpenSSL should be added as a recommends: for the libqt4-network package. But in todays crypto-heavy world, I can't really think of a good reason not to just link it. Among other things, Qt's web widgets (and URL classes) will not support https without libssl/libcrypto. I still haven't tested recompiling Qt. I'll do so tonight, and if it works, we should probably reassign this to libqt4-network so a permanent fix can be included for the future. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
