Debian Bug report logs - #513089
putty-tools: this package should be a provider of virtual "ssh-client"

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Salvador Fandino <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: putty-tools: this package should be a provider of virtual "ssh-client"

Date: Mon, 26 Jan 2009 10:20:49 +0100

Package: putty-tools
Version: 0.60-4
Severity: minor


This package includes "plink" that is a full feature command line SSH client.

Cheers,

 - Salva

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages putty-tools depends on:
ii  libc6                         2.7-18     GNU C Library: Shared libraries

putty-tools recommends no packages.

putty-tools suggests no packages.

-- no debconf information

Message #10 received at [email protected] (full text, mbox, reply):

From: Colin Watson <[email protected]>

To: Salvador Fandino <[email protected]>, [email protected]

Subject: Re: Bug#513089: putty-tools: this package should be a provider of virtual "ssh-client"

Date: Sun, 22 Feb 2009 22:51:58 +0000

On Mon, Jan 26, 2009 at 10:20:49AM +0100, Salvador Fandino wrote:
> This package includes "plink" that is a full feature command line SSH client.

I think adding such a Provides would cause problems. plink does not
provide a particularly OpenSSH-compatible interface - if nothing else,
it does not provide /usr/bin/ssh! - and various other packages depend on
ssh-client with the apparent intention of using such an interface.
Surely, at minimum, plink would need to install an alternative for
/usr/bin/ssh, and openssh-client would need to be changed to do the
same, before we could make this change. Doing that would in turn require
us to define some reasonable minimal subset of the command-line
interface that other packages could rely on.

I'm not sure that all of this isn't more trouble than it's worth; it
seems as if it would create a lot of complexity and fragility for very
little gain. Do you have a concrete reason for needing this?

Thanks,

-- 
Colin Watson                                       [[email protected]]

Send a report that this bug log contains spam.