[ On Tuesday, October 22, 2002 at 15:31:31 (-0400), gabriel rosenkoetter wrote: ]
> Subject: Re: pkg/18729: security/ssh should conflict with security/ssh2
>
> On Sat, Oct 19, 2002 at 04:26:02PM -0400, Greg A. Woods wrote:
> > 	security/ssh should conflict with security/ssh2
> 
> Why?

because it conflicts!  ;-)

> Unless the world has changed drastically since the last time I used
> FSecure SSH on a Unix-like system (admittedly, more than a little
> while ago), security/ssh installs itself as ssh[d]1[-*], then sym
> links to ssh[d,-*] to it. security/ssh2 installs itself as ssh[d]2[-*]
> and then sym links ssh[d,-*] to itself.

Yes, the world has changed drastically in that interval, especially the
part directly surrounding SSH!  ;-)

If you examine the security/ssh2 pkgsrc module you'll find that it is
configured to provide internal ssh1 client compatability (the only kind
that's even remotely sane to allow by default, though I'm not 100%
certain that what's ended up in the package in the official pkgsrc is
entirely and properly restricting any accidental use of any
un-registered ssh1 files).  You'll also find that it installs and
registers the filenames and symlink names that do not include any
version identifier.

I.e. security/ssh2 directly and unresolvably convlicts with security/ssh.

> If you install security/ssh2 first and then security/ssh1 second,
> you deserve what you get. Perhaps a warning in MESSAGE is in order,
> but I don't see why they need to conflict; the only overlapping 
> files should be sym links (provided our patches aren't changing
> that install behavior).

They must conflict unless neither installs the unversioned filenames and
there's some pair of optional packages invented to install the symlinks
that choose the default.  Such a combination of packages has no
practical application though -- ssh1 is deprecated and should never be
used in any new environment.  Those with ssh1 should be aggressively
upgrading all of their servers and they can use the internal client
compatability to continue to connect to whatever few sshd1 servers they
have not yet upgraded (or cannot upgrade due to their existance in some
closed environment that cannot be easily changed without vendor support).


-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>