It should be possible to run Kleopatra VSD and Kleopatra GPD at the same time. Currently, this isn't possible because Kleopatra is a/uses KUniqueService. Both versions use a different GNUPGHOME so that a more general solution based on GNUPGHOME would be a possible solution.
This is closely related to T7040, but I'd like to keep this separate.
Note: This will only be supported by vsd 4 (because it uses a separate GNUPGHOME)
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Testing | None | T7040 Make it possible to install GnuPG VSD and GPD in parallel | ||
| Testing | • ikloecker | T7528 Make it possible to run Kleopatra VSD and Kleopatra GPD in parallel | ||
| Invalid | • ikloecker | T7758 Kleopatra: Make the registry path for the GnuPG install directory customizable | ||
| Resolved | timegrid | T8008 GpgEX: UI server already running |
Remarks:
All changes have been backported for VSD 3.4 (because they are closely entwined with changes for T7717).
Regarding testing: The next Gpg4win 5 beta can already run concurrently with VSD 3.3. The only problem is that an error about the Windows Explorer integration is shown because only one of the two Kleopatras can listen to the UI server socket. This might be fixed at least partially with VSD 3.4 which will used a different GNUPGHOME.
But there are more fundamental problems that need to be fixed with the Windows Explorer integration (see T7969: GpgEX: Support concurrently running Kleopatras).
Seems to work in principle with gpg4win-5.0.2-beta2 and vsd-4.0.0-beta1203.
I'll wait for a new vsd beta release (with some fixes) for further testing.
Note: If both are installed, GpgOL of vsd seems to be used (or the last installed).
Issues found
I never expected this this to work with vsd34, only with vsd4.0. We could remove the vsd34 tag and add only the vsd tag.
Up to @ikloecker.
I don't think that any of the found issues are up to me. The only real issues seem to be issues with the VSD 3.4 MSI and the MSI is way out of my responsibility. Maybe @m.eik wants to have a look at this especially since the build process for VSD 3.4 and VSD 4 is largely identical.
If the VSD 3.4 MSI installs to ...\Gpg4win although it should install to GnuPG VS-Desktop then that's an MSI issue.
- Starting vsd kleopatra displays kleopatra.exe org.kde.pim.kleopatra: Looking for VERSION file: "C:/Program Files (x86)/Gpg4win/bin/../VERSION" in debugview.
There's nothing wrong with this. Kleopatra simply looks for the VERSION file relative to its own location.
- Starting gpg4win kleopatra afterwards displays this error:
Installing gpgex for VSD and Gpg4win/GPD makes no sense and is bound to cause trouble. Neither gpgex nor gpgol must be installed for VSD and Gpg4win/GPD. Only the parallel installation of Kleopatra is supported.
- gpgconf -X in vsd kleopatra displays the correct gpg version (2.2.54), all paths point to Gpg4win (e.g. bindir:C%3a\Program Files (x86)\Gpg4win\GnuPG\bin)
- gpg --version in cmd displays the gpg4win version (2.5.21), so it is somehow still executable
Not sure where you see the issue. Maybe VSD didn't add its path to the PATH variable. No idea if this is intentional. Looks again like an MSI issue.
- Starting gpg4win kleopatra afterwards displays this error:
Installing gpgex for VSD and Gpg4win/GPD makes no sense and is bound to cause trouble. Neither gpgex nor gpgol must be installed for VSD and Gpg4win/GPD. Only the parallel installation of Kleopatra is supported.
Interesting, this might need to be communicated somewhere. Best would probably be a warning in the installation process?
- gpgconf -X in vsd kleopatra displays the correct gpg version (2.2.54), all paths point to Gpg4win (e.g. bindir:C%3a\Program Files (x86)\Gpg4win\GnuPG\bin)
- gpg --version in cmd displays the gpg4win version (2.5.21), so it is somehow still executable
Not sure where you see the issue. Maybe VSD didn't add its path to the PATH variable. No idea if this is intentional. Looks again like an MSI issue.
It was a bit surprising, as vsd was installed last and might have partially overwritten the gpg4win installation. I haven't looked deeper into it, just wanted to share some first impressions of the current state to discuss.
- Starting gpg4win kleopatra afterwards displays this error:
I misread this initially. If I understand correctly then you started kleopatra from VSD and then kleopatra from Gpg4win while kleopatra VSD was still running? This isn't going to work because GnuPG VSD is using the same GNUPGHOME as GnuPG Gpg4win. That's why there's a collision of the uiserver socket file that kleopatra creates (or tries to create). But there are likely much more serious problems with GnuPG VSD and GnuPG Gpg4win working on the same GNUPGHOME and, more importantly, probably sharing the same socket names for gpg-agent, scdaemon, etc.
That's right.
This isn't going to work because GnuPG VSD is using the same GNUPGHOME as GnuPG Gpg4win.
I see. Then this will only work with vsd4. I'll remove the vsd34 tag and add vsd.
I quickly tested gpg4win-5.1.0 + vsd-4.0.0-beta1350-nowin @ win10, and it works:
Thorough tests are still needed.
Note: independent of the installation order, cmd uses the gpg bin from gpg4win. The desired behavior needs to be specified.