What about adding Provides: ssh-agent = %version-%release ? gnupg2 package has similar thing for gpg-agent, and it's good, since "agents" are not libraries, but some other programs may depend on their existence.
А смысл? Наличие или отсутствие функциональности, предосталяемой ssh-agent не зависит от наличия этого ssh-agent на конкретном хосте. См. напр. ForwardAgent.
Ну хорошо, у меня просто есть конкретный пример: есть такая программа, seahorse-agent, которая интегрируется с ssh-agent, в частности, показывает в графике запрос SSH passphrase. Сейчас она требует openssh-clients, но по-хорошему, ей нужны не клиенты, а ssh-agent.
А ведь Raorn прав, нужен $SSH_AUTH_SOCK а не ssh-agent.
Ну в принципе да, но всё равно нужна какая-то ручка, за которую можно вытянуть пакет, эквивалентный ssh-agent в смысле установки SSH_AUTH_SOCK. Как этот Provides будет называться, мне почти всё равно. Например, ssh-agent :)
Наличие ssh-agent(1) ещё не даёт возможности использовать $SSH_AUTH_SOCK, а из наличия $SSH_AUTH_SOCK не следует наличие установленного ssh-agent(1) или аналога. Я не понимаю, зачем может быть нужно в пакете иметь зависимость на виртуальный пакет, который содержит утилиту с неизвестным именем, которая может создавать $SSH_AUTH_SOCK. Кроме того, в пакете openssh-clients есть /etc/X11/profile.d/ssh-agent.sh
На текущий момент пакету seahorse-agent требуется и то, и другое (почему - это, кстати, тема отдельного разговора). Самому агенту нужен (если ничего не путаю) только $SSH_AUTH_SOCK, агент работает как прокси, выставляя в X-сессии свой SSH_AUTH_SOCK. А сама программа ssh-agent, а точнее, этот самый /etc/X11/profile.d/ssh-agent.sh, его запускающий, сейчас нужен потому, что /etc/X11/profile.d/seahorse-agent.sh пытается его дёргать, если не обнаруживает $SSH_AUTH_SOCK.
Чем дальше, тем менее понятно. Давайте пойдём в devel@, здесь обсуждать неудобно.
Не вижу проблемы.