From owner-freebsd-ports Sun Oct 10 18:35: 8 1999 Delivered-To: freebsd-ports@freebsd.org Received: from guru.phone.net (guru.phone.net [216.240.39.120]) by hub.freebsd.org (Postfix) with SMTP id 50052150FE for ; Sun, 10 Oct 1999 18:35:04 -0700 (PDT) (envelope-from mwm@phone.net) Received: (qmail 48246 invoked by uid 100); 11 Oct 1999 01:35:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Oct 1999 01:35:04 -0000 Date: Sun, 10 Oct 1999 18:35:04 -0700 (PDT) From: Mike Meyer To: freebsd-ports@FreeBSD.ORG Subject: Re: install newer version over old one... In-Reply-To: <19991010173703.A74118@rucus.ru.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 10 Oct 1999, Neil Blakey-Milner wrote: :->On Sat 1999-10-09 (13:07), Mike Meyer wrote: :->> :->You can't expect to have a vim-4.3.2 package and a vim5-5.0.1 :->> :->package. :->> Question - can we expect that everyone will *eventually* move to vim :->> 5? Or, for my favorite example, the gtk1# ports - don't we expect that :->> eventually the earlier versions will vanish as other ports move to the :->> new ones? :->This has nothing to do with whether or not people _will_ upgrade, :->but rather about what the upgrade path _is_. If a person used :->vim4, there is no reason that person won't use vim5 eventually. No, it's about "will" - or maybe "can". I'm not familiar with vim, but I suspect the upgrade path consists of nothing more than a pkg_delete on vim4 followed by pkg_add on vim5 (if that doesn't work on vim, there are packages it does work on). :->> :->What we really need is a mechanism to show the scope of upgrades :->> :->- whether ssh-2.0.0 _really_ upgrades ssh-1.2.27. :->> Unless "really" means "we can expect all users to move to some point :->> in the future", this isn't right. From what I can tell, ssh2 upgrades :->> ssh1 in every technical sense. :->They are not compatible. ssh2 needs ssh1 to be around to access :->sshd1. ssh1 can't talk to sshd2. That just reinforces my point - which is that ssh2 & ssh1 aren't really the same product. There is an upgrade path - buy the appropriate license for ssh2, install ssh2 with ssh1 compatibility, get your users to buy licenses (as needed) for ssh2 by announcing a date for ssh1 support stopping, then deal with the repercussions from your users when you actually turn it off. There are enough obstacles to doing so that many people aren't going to do it. I won't, because neither my ISP nor my clients are going to. Upgrading from vim4 to xemacs-21 is probably easier.