FS#47288 - [ksshaskpass] 5.4.3-1 conflicts with x11-ssh-askpass (seahorse)
Attached to Project:
Arch Linux
Opened by Moabit (Moabit) - Monday, 07 December 2015, 00:15 GMT
Last edited by Antonio Rojas (arojas) - Tuesday, 22 December 2015, 22:30 GMT
Opened by Moabit (Moabit) - Monday, 07 December 2015, 00:15 GMT
Last edited by Antonio Rojas (arojas) - Tuesday, 22 December 2015, 22:30 GMT
|
Details
Background:
I have plasma-meta 5.4-2 installed, which depends on ksshaskpass 5.4.3-1. I'm using gnome-keyring to store passwords for mutt and associated command-line utilities. AFAIK the only way to manage the keyring is via seahorse [1]. Problem: Seahorse conflicts with ksshaskpass. Hence, I would have to uninstall plasma-meta in order to install seahorse and manage Gnome Keyring. Seahorse (3.18.0-1) and ksshaskpass both provide x11-ssh-askpass. However, ksshaskpass also conflicts with x11-ssh-askpass. I can see no file conflicts. Is it okay to just remove this conflict? [1] https://wiki.archlinux.org/index.php/GNOME_Keyring#Manage_using_GUI |
This task depends upon
Closed by Antonio Rojas (arojas)
Tuesday, 22 December 2015, 22:30 GMT
Reason for closing: Fixed
Additional comments about closing: Dropped SSH_ASKPASS from ksshaskpass, seahorse, x11-ssh-askpass, openssh-askpass
Tuesday, 22 December 2015, 22:30 GMT
Reason for closing: Fixed
Additional comments about closing: Dropped SSH_ASKPASS from ksshaskpass, seahorse, x11-ssh-askpass, openssh-askpass
* Notify users that they should manually set SSH_ASKPASS (as you say).
* Bundle a small script, similar to `archlinux-java`, that sets SSH_ASKPASS.
* Set it according to the current DE (but this is perhaps too prescriptive).
Also, I forgot to add the link, but I originally asked in the forums. Apparently I'm not the only one that would like to install both.
https://bbs.archlinux.org/viewtopic.php?pid=1564208
I built and installed ksshaskpass without the conflicts, and installed seahorse in parallel. This appears to be working perfectly so far.
1) having each askpass package provide 'ssh-askpass', and
2) depending on that instead of specific packages?
If that dependency would be changed, then ASKPASS could still be set by the package.
There would be no problem as long as users do not want to install more than one askpass package at once.
Anyway, not setting SSH_ASKPASS is also fine by me.
Hence for me, any solution that kept the conflicts might improve the situation, but not fix my particular problem.
In any case, I still think that the standard case should not need manual setting of env variables. But as I said, I'll go with the majority here.