Help Wizard

Step 1


Spotify 1: depend on both libssl 1.0.0 and 1.0.2?

Spotify 1: depend on both libssl 1.0.0 and 1.0.2?

➜  ~ ldd /usr/bin/spotify | grep ssl => not found => /usr/lib/x86_64-linux-gnu/ (0x00007f45d7d60000)

libssl 1.0.0 isn't available anymore in Debian testing,  any particular reason to be dependent on both 1.0.0 and 1.0.2?

3 Replies

The Spotify client depends on libssl to start a webserver that Spotify Play Button can talk to.


Unfortunately, the way the library is linked means it is the same version of the library that it builds with, which is


The Spotify client also depends libcurl. Libcurl in turn, depends on the libssl, the same version of the library that it was built with, which is libssl.1.0.2


So, on systems that only has libssl.1.0.0 (like Ubuntu, which decided to not change the so-name of the library, while still make sure it has all the security fixes) Spotify only depends on one version of the library.


$ ldd /usr/bin/spotify | grep -e ssl -e curl => /usr/lib/x86_64-linux-gnu/ (0x00007f1829b29000) => /lib/x86_64-linux-gnu/ (0x00007f18298c0000)
$ ldd /usr/lib/x86_64-linux-gnu/ | grep ssl => /lib/x86_64-linux-gnu/ (0x00007f46dd25d000)

This is a big problem that needs to be solved.


Shouldn't the package specify what shared libraries it's depended on in the deb package itself as well as what versions? Assuming a certain shared library version should exist without a dependency chain makes no sense. I'm no expert on debian packaging but after skimming through debian policy on shared libs[1] this just looks wrong.


Any idea as when this can be fixed? I haven't been able to use Spotify on my Linux box for some time now and this is my major use case.






Any response? Why can't you folks sort out an public issue tracker?

Suggested posts