/usr/local should be reserved for local / admin installations. Our packages should not install any files here, but currently we are: # rpm -ql `rpm -qa | grep thinlinc | grep -v debug` | grep /usr/local /usr/local/share/applications/thinlinc-webadm.desktop /usr/local/share/applications/thinlinc-webaccess.desktop /usr/local/share/applications/thinlinc-setup.desktop /usr/local/share/applications/thinlinc-client.desktop The cause is that xdg-utils prefers /usr/local/share over /usr/share. As far as I can tell, in our version, the paths are hardcoded, but it is probably sufficient to do like this: perl -pi -e 's|/usr/local/share/:/usr/share/|/usr/share:/usr/local/share|g' *.in perl -pi -e 's|/usr/local/share:/usr/share|/usr/share:/usr/local/share|g' *.in But first of all, we should upgrade xdg-utils.
http://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local
We are already installing some things under /usr, e.g. thinlinc-login, which means we are a bit inconsistent.
https://lists.freedesktop.org/archives/xdg/2009-August/010952.html
Did as trivial bug. We are running 1.1.1 and there's a 1.1.2 release, but it doesn't fix this, thus manual change. The tester should check that our packages installs no files to /usr/local.
The resulting change of this bug is that the call to `xdg-desktop-menu` in %post and %preun steps in out spec files, always returns true even if the command fails; - xdg-desktop-menu uninstall /opt/thinlinc/lib/tlclient/thinlinc-client.desktop + # Some platforms tries to install to /usr/local, which might be read only + xdg-desktop-menu uninstall /opt/thinlinc/lib/tlclient/thinlinc-client.desktop || true This will silent the error when there is an issue writing to /usr/local/ without permissions. Tested using ThinLinc build 5672 and installation does not fail on a system were /usr/local is read only to root. Maybe we should log this failed attempt due to consequences are that no desktop files are installed for the client or related server components (tl-setup etc.)... And they are not found in gui start menus.
(In reply to comment #8) > The resulting change of this bug is that the call to `xdg-desktop-menu` in > %post and %preun steps in out spec files, always returns true even if the > command fails; > This will silent the error when there is an issue writing to /usr/local/ > without permissions. Actually, this test case was too simple. I've recreated the case in Issue 19926 with: # mount -o ro fileserver:/export/archive/cendio-build /usr/local # rpm -vhi thinlinc-client-4.8.0post-5672.x86_64.rpm Preparing... ########################################### [100%] 1:thinlinc-client ########################################### [100%] error: unpacking of archive failed: cpio: mkdir failed - No data available This means that the fix is not enough - we also need to change the ghost entries. Which is a good idea, IMHO. Wrt to xdg-desktop-menu, it actually provides output if it fails: # xdg-desktop-menu install /opt/thinlinc/lib/tlclient/thinlinc-client.desktop || true xdg-desktop-menu: No writable system menu directory found. (Did this test with the mount above, plus renamed /usr/share/desktop-directories to /usr/share/desktop-directories.disabled).
Mounted a read-only filesystem on /usr/local, replaced system-wide xdg-desktop-menu with a link to /bin/false to simulate a failing xdg command. Ran 'sudo dpkg -i thinlinc-client_4.8.0post-5692_amd64.deb' on an Ubuntu 16.04. Installation worked as expected with no failures. 'tlclient' was installed in /opt/thinlinc/bin. The desktop file was not installed but the installation finished ok, so no attempt to write in /usr/local was detected nor did the installation abort because of a failed xdg-command. Closing.
