From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 18:36:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA5B61065675 for ; Wed, 11 Jun 2008 18:36:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 77AA88FC0C for ; Wed, 11 Jun 2008 18:36:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E98C246C4A; Wed, 11 Jun 2008 14:36:28 -0400 (EDT) Date: Wed, 11 Jun 2008 19:36:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Paul Schmehl In-Reply-To: <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> Message-ID: <20080611193123.N40102@fledge.watson.org> References: <484FA07E.60103@lozenetz.org> <3cc535c80806110536w1c8af6efq8d5470ce6de8cb38@mail.gmail.com> <20080611165009.O40102@fledge.watson.org> <4E2C3BF30A4BC75D1D837828@utd65257.utdallas.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, mh@kernel32.de Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2008 18:36:29 -0000 On Wed, 11 Jun 2008, Paul Schmehl wrote: > From a security standport, backporting fixes to previous versions of ports > creates a difficulty. It's much harder to tell, for example, if a RedHat > "port" is vulnerable or not, because RedHat uses their own proprietary > versioning system to define "where" a particular "port" is at. > > So, while your system might *say* it's running php version 5.2, it's really > *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm > just making that up.) > > If this idea ever gets off the ground, I *hope* the folks involved with find > a rational, logical way to define the versioning so that it's not > hieroglyphics to the average person. I hope not to offend the ports folks in saying this, but it seems clear to me that the narrower scope and better-defined components of the base system have (over time) lead to a much easier incremental upgrade path than ports and packages. It's not clear to me how you could apply the same level of attention to something as large as the ports collection, except perhaps to select a subset of ports you care "more" about, and provide a higher quality of service for them. In effect, try to find a semantically richer middle ground between "it's someone else's problem, our role is primarily to bundle" and "it's entirely our problem and in revision control". We already do this for some ports, in that the people involved in adapting and maintaining some of the larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, spend vast amounts of time ensuring that things work well, but largely without the help of revision control in the ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we could better present the choices reflected there. That doesn't help users of random tiny software packages, and I'm not sure anything can, but perhaps we can provide a smoother incremental maintenance path for some key packages. Mind you, ports really isn't my area, so I am at significant risk speculating in this area. Experience with the base system shows that the real work is always in the details, and hardly ever in the big ideas, and so only by truly implementing a system and trying it out can you determine whether it really works in practice. It's easy to wave ones hands at a high level (as I've done), but it's the proof-of-concept that matters. Robert N M Watson Computer Laboratory University of Cambridge