Bug 7183 - upgrading the client or server makes the .desktop file go away on RPM systems
Summary: upgrading the client or server makes the .desktop file go away on RPM systems
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.3.1
Hardware: PC Linux
: P2 Normal
Target Milestone: 4.10.0
Assignee: Peter Åstrand
URL:
Keywords: relnotes, samuel_tester
Depends on:
Blocks:
 
Reported: 2018-05-21 08:41 CEST by Pierre Ossman
Modified: 2022-04-22 07:59 CEST (History)
3 users (show)

See Also:
Acceptance Criteria:
* Working ThinLinc launcher icon(s) should be installed on the system, both when installing the client/server for the first time and when upgrading an older version. * ThinLinc icons should be installed and usable, for example when creating a new launcher on the desktop. * .tlclient files should be associated with the ThinLinc client * It should be possible to install the client package on systems where /usr/local is read only (see bug 5941). * No files should be left behind when uninstalling the client/server package. * Client update functionality should work, if xdg-open is installed * Server launchers for webaccess and tlwebadm should work, if xdg-open is installed.

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Pierre Ossman cendio 2018-05-21 08:41:47 CEST 
When upgrading from 4.8.0 to 4.9.0 the .desktop file for the ThinLinc client goes missing. I suspect it is fallout from bug 5941 as rpm will most likely think that /usr/local/share/applications/thinlinc-client.desktop is from the old version and should be removed (since the old version has a %ghost entry and the new does not).
Comment 2 Pierre Ossman cendio 2018-05-21 09:18:40 CEST 
The same system is used in the server, so it is equally affected.
Comment 4 Pierre Ossman cendio 2018-05-22 13:01:14 CEST 
Let's start by seeing what we can do so that people upgrading 4.8.0 => 4.10.0 won't suffer from this.
Comment 5 Peter Åstrand cendio 2018-05-22 15:16:17 CEST 
(In reply to comment #4)
> Let's start by seeing what we can do so that people upgrading 4.8.0 => 4.10.0
> won't suffer from this.

Assuming we are not going back to specifying /usr/local for the .desktop file in our RPM (which would bring back bug 5941), it seems to me that there is no way of avoiding this problem as long as /usr/local is actually used for the .desktop file. In other words, we need to stop using /usr/local, which in turn means that we need to stop using "xdg-desktop-menu" (at least versions from the system). We should consider either always using our own version of xdg-desktop-menu (patched to use /usr/), or do things by hand instead. I think we should try the latter approach. xdg-desktop-menu is big and magic; 1367 lines. For example, it tries to use "xprop" to determine the desktop environment, but this will fail if you install a RPM package via SSH with X11 forwarding enabled, and the forwarded display uses a different DE.
Comment 6 Pierre Ossman cendio 2018-11-19 11:55:48 CET 
Yes, I'd like us to explore the option of avoiding all magic and just having the files in the proper location already from the start. I.e. the same way Red Hat (and all other distributions?) package things for their own packages.

We need to check if we still need some magic to update MIME types properly.
Comment 16 Peter Åstrand cendio 2018-12-05 09:39:39 CET 
See also bug 5090.
Comment 17 Peter Åstrand cendio 2018-12-05 10:19:42 CET 
See also bug 5937.
Comment 19 Peter Åstrand cendio 2018-12-05 15:50:00 CET 
I've been testing on:

* RHEL7 Server

* SLES12SP3

* Ubuntu 18.10 Desktop
Comment 20 Samuel Mannehed cendio 2019-01-03 16:52:48 CET 
Verified that this is now fixed on the following platforms:

* Ubuntu 14.04
* RHEL 6
* SLES 15
* Fedora 29

Tested both client package and server packages. Verified the following:

* Upgrade from 4.8.1 to 4.9.0 causes .desktop files to disappear on RPM systems
* Upgrade from 4.8.1 to nightly works
* Upgrade from 4.9.0 to nightly works
* Fresh install causes the .desktop files to show right away without having to logout
Comment 21 Pierre Ossman cendio 2019-02-27 14:25:18 CET 
I think something is broken here. The client lost its icon when upgrading on both the Eltex and HP ThinPro terminals. I'm guessing this bug is the cause.
Comment 23 Pierre Ossman cendio 2019-02-27 15:26:11 CET 
It was the same for the RPMs apparently.

Did a fix, but on second thought that is probably not a good one as it requires us to be able to install things in /usr/share/icons. That might not be the case on terminals or other special systems.
Comment 25 Pierre Ossman cendio 2019-02-27 15:39:42 CET 
Should be fixed now.

Tester should check that we get a window icon with all Linux packaging variants. Remember to verify using xprop as GNOME and such ignore the window icon and use other methods.
Comment 26 Peter Åstrand cendio 2019-03-05 12:15:41 CET 
(In reply to comment #25)
> Should be fixed now.
> 
> Tester should check that we get a window icon with all Linux packaging
> variants. Remember to verify using xprop as GNOME and such ignore the window
> icon and use other methods.

Commits inspected, looks good. Changes only applies to Linux. Tested TGZ, RPM, and DEB package; works fine.
Comment 27 Peter Åstrand cendio 2019-03-06 13:25:48 CET 
tl-setup now lacks an icon, due the the location/name changes.
Comment 29 Peter Åstrand cendio 2019-03-11 11:59:19 CET 
(In reply to comment #27)
> tl-setup now lacks an icon, due the the location/name changes.

Works now.
Note You need to log in before you can comment on or make changes to this bug.