Description of problem: $ tracker-preferences tracker-preferences: error while loading shared libraries: libtracker-common.so.0: cannot open shared object file: No such file or directory $ rpm -ql tracker|grep common /usr/lib64/tracker-1.0/libtracker-common.so.0 /usr/lib64/tracker-1.0/libtracker-common.so.0.0.0 Version-Release number of selected component (if applicable): 0.17.8-3.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
$ /usr/libexec/tracker-miner-fs /usr/libexec/tracker-miner-fs: error while loading shared libraries: libtracker-extract.so.0: cannot open shared object file: No such file or directory $ tracker-control tracker-control: error while loading shared libraries: libtracker-data.so.0: cannot open shared object file: No such file or directory
Does running /sbin/ldconfig as root fix this?
What is the output of 'ls -l /usr/lib64/tracker-1.0/libtracker-data.so.0' and 'rpm -V tracker' ?
tracker-0.17.5.2 -> updating to 0.17.8-3 Error while loading shared libraries # /sbin/ldconfig $ tracker-control tracker-control: error while loading shared libraries: libtracker-data.so.0: cannot open shared object file: No such file or directory $ rpm -V tracker ....L.... /usr/lib64/tracker-1.0/libtracker-common.so.0 ....L.... /usr/lib64/tracker-1.0/libtracker-data.so.0 ....L.... /usr/lib64/tracker-1.0/libtracker-extract.so.0 Downloading to 0.17.8-1 in koji -> updating to 0.17.8-3 Fixed! Strange :(
I am unsure how the ld.so cache exactly works, but my working theory is that it has something to do with the rebuilding of ld.so cache during the updates. Looking at the 'rpm -V' output you posted, it looks like broken so.0 symlinks in the private directory. During the upgrade, what happens is: 1) The old package has /etc/ld.so.conf.d/tracker-x86_64.conf installed 2) New package is installed, /etc/ld.so.conf.d/tracker-x86_64.conf stays in place 3) New package's %post runs ldconfig 4) Old package is removed, removing /etc/ld.so.conf.d/tracker-x86_64.conf And this somehow trashes the private .so.0 symlinks. I think a workaround would be to add back /etc/ld.so.conf.d/tracker-x86_64.conf, but as an empty file. This should make sure ldconfig no longer considers the private directory when the new package's %post runs.
I've added it back as an empty file in http://pkgs.fedoraproject.org/cgit/tracker.git/commit/?id=b0ffed261f53b2cd3586e71b89366d408904da2a. This workaround should only be needed for tracker 0.17.x -> 0.17.x / 0.18.x updates so we don't need to keep it in place for long. 0.16.x updates are unaffected because the private dir changed in the mean time.