From owner-freebsd-stable@FreeBSD.ORG Thu Jan 5 09:26:31 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 315D016A41F; Thu, 5 Jan 2006 09:26:31 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E41E43D4C; Thu, 5 Jan 2006 09:26:30 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k059PupC007295; Thu, 5 Jan 2006 01:26:29 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k059Omnt008120; Thu, 5 Jan 2006 01:24:48 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id k059OmHL008119; Thu, 5 Jan 2006 01:24:48 -0800 (PST) (envelope-from jrhett) Date: Thu, 5 Jan 2006 01:24:48 -0800 From: Jo Rhett To: "Daniel O'Connor" Message-ID: <20060105092448.GH1358@svcolo.com> Mail-Followup-To: Daniel O'Connor , freebsd-stable@freebsd.org, Chuck Swiger , stable@freebsd.org, current References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> <200512231136.12471.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512231136.12471.doconnor@gsoft.com.au> Organization: svcolo.com User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) 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: Thu, 05 Jan 2006 09:26:31 -0000 On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote: > On each 'client' PC.. > NFS mount /usr/src and /usr/obj > installkernel > reboot > installworld Works fine on home computers behind firewalls. Useless on public servers that don't run RPC. Useless on flash-based servers where minimizing writes is necessary. (mergemaster does far far far too many writes) > You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say "we'll support this". I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. > I find it very hard to believe > that core would suggest someone NOT implement a good framework for doing full > binary upgrades via the network. A good binary update mechanism shouldn't be just the network. Updates from flash devices, ISO images, etc should all work much the same way. > Unless you mean "core@ said they would not support packaging the base" which > is different. People have clearly identified the problems that prevent a useful binary update mechanism from working, and what they need from core. Some have asked for core packages, others have other ideas, and some have said "anything that gives me versioning ability" and > > For binary upgrades without booting from CD-ROM to be possible, we need > > versioning of some sort at the OS level. Core OS packages are the most > > This is not true - I don't see it as being mandatory to be able to apply > binary updates. (Case in point - freebsd-update works fine without it) freebsd-update works "fine" if you run GENERIC with no build options. Back to "useful for home computers". freebsd-update is hampered by the exact problems I'm listing here. Difficulty determining "what I have", no method to store "what I did" and no effective backout mechanism to speak of. Nobody that I know cares whether or not the solution manifests as core os packages, but some sort of core versioning ability has to be developed and supported by the core. > > popular suggestion, but not the only path. Every year this topic comes up > > and gets struck down again. > > Yes, because a) it isn't necessary, b) it may not solve the problem, c) there > are no patches to evaluate. > > I think the people suggesting it see it as a panacea to fix their problems but > haven't fully evaluated it. You're arguing my own points. Again, nobody (that I know) cares that it manifests as core OS packages. Certainly the existing package system used for ports wouldn't work as-is for this task. But the have/did/undo problems remain to be solved. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation