www.cendio.com
Bug 7183 - upgrading the client or server makes the .desktop file go away on RPM systems
: upgrading the client or server makes the .desktop file go away on RPM systems
Status: CLOSED FIXED
: ThinLinc
Other
: 1.3.1
: PC Linux
: P2 Normal
: 4.10.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2018-05-21 08:41 by
Modified: 2019-03-12 12:40 (History)
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


Note

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


Description From cendio 2018-05-21 08:41:47
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 From cendio 2018-05-21 09:18:40 -------
The same system is used in the server, so it is equally affected.
------- Comment #3 From cendio 2018-05-21 09:33:39 -------
https://fedoraproject.org/wiki/Packaging:Scriptlets#Ordering
------- Comment #4 From cendio 2018-05-22 13:01:14 -------
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 From cendio 2018-05-22 15:16:17 -------
(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 From cendio 2018-11-19 11:55:48 -------
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 From cendio 2018-12-05 09:39:39 -------
See also bug 5090.
------- Comment #17 From cendio 2018-12-05 10:19:42 -------
See also bug 5937.
------- Comment #19 From cendio 2018-12-05 15:50:00 -------
I've been testing on:

* RHEL7 Server

* SLES12SP3

* Ubuntu 18.10 Desktop
------- Comment #20 From cendio 2019-01-03 16:52:48 -------
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 From cendio 2019-02-27 14:25:18 -------
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 From cendio 2019-02-27 15:26:11 -------
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 From cendio 2019-02-27 15:39:42 -------
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 From cendio 2019-03-05 12:15:41 -------
(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 From cendio 2019-03-06 13:25:48 -------
tl-setup now lacks an icon, due the the location/name changes.
------- Comment #29 From cendio 2019-03-11 11:59:19 -------
(In reply to comment #27)
> tl-setup now lacks an icon, due the the location/name changes.

Works now.