From owner-freebsd-ports Sat Oct 9 13: 8: 7 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 823E414C80 for ; Sat, 9 Oct 1999 13:07:59 -0700 (PDT) (envelope-from mwm@phone.net) Received: (qmail 32903 invoked by uid 100); 9 Oct 1999 20:07:59 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Oct 1999 20:07:59 -0000 Date: Sat, 9 Oct 1999 13:07:59 -0700 (PDT) From: Mike Meyer To: freebsd-ports@FreeBSD.ORG Subject: Re: install newer version over old one... In-Reply-To: <19991009101642.A80651@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 Sat, 9 Oct 1999, Neil Blakey-Milner wrote: :-> :->On Fri 1999-10-08 (22:15), Scot W. Hetzel wrote: :->> Then the ssh2 port needs to have it's package name changed to ssh2-2.0.13. :->No, it shouldn't. :->I mean, at one stage we had vim, and vim5, where vim was version :->4, and vim5 was version 5. I agree in general, but disagree in this instance. :->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? :->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. Unfortunately, the new licensing restrictions mean that some people can't or won't use the newer version, and support is coming from a group other than the original developers. So what we really have are two *different* products from a common code base. Possibly what I'm arguing is that the "mechanism" you're asking for be the package name - sans version number, and package/port names that include a version number as part of the name should be avoided at all costs.