From owner-freebsd-stable@FreeBSD.ORG Sun Feb 27 02:58:34 2011 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 8B8D51065670; Sun, 27 Feb 2011 02:58:34 +0000 (UTC) (envelope-from jhelfman@experts-exchange.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id 229FC8FC17; Sun, 27 Feb 2011 02:58:34 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id 0815D6F4F5B; Sat, 26 Feb 2011 18:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=e-e.com; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received:received; s=ee; t= 1298775513; x=1300589913; bh=aL1meeohjy8761CDuSyS6g2gm4QGqXBUGHB f5gkCUkQ=; b=JI8+gUyfCh6hrQKWXA45hmJYt1p6NYJpKVigwjU52bpw4coL8cG b1VyKP/PhL25BuUcQK0ukPWW/wLxjNQ3OmxCGFO4VvaMQWCSk2a04bhoJrenli7T Ef9LFNAOEVSyoriaglFsINZuD8MO2+cpxHdQTP9XoTfEyYPYWuFh6tzE= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XEP2t4ybYbZ; Sat, 26 Feb 2011 18:58:33 -0800 (PST) Received: from experts-exchange.com (unknown [72.29.180.81]) by mail.experts-exchange.com (Postfix) with SMTP id A7FA36F4F56; Sat, 26 Feb 2011 18:58:33 -0800 (PST) Received: (nullmailer pid 64268 invoked by uid 1001); Sun, 27 Feb 2011 02:55:12 -0000 Date: Sat, 26 Feb 2011 18:55:12 -0800 From: Jason Helfman To: John Baldwin Message-ID: <20110227025512.GA64170@eggman.experts-exchange.com> References: <4D66CCFF.9020903@buffalo.edu> <20110225160109.GA32260@lava.net> <20110225180019.GD76063@eggman.experts-exchange.com> <201102251501.11318.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <201102251501.11318.jhb@freebsd.org> X-Operating-System: FreeBSD 8.2-RELEASE X-Living-The-Dream: I love the SLO Life! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, cperciva@freebsd.org Subject: Re: 8.2/7.4-RELEASEs Announced... 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: Sun, 27 Feb 2011 02:58:34 -0000 On Fri, Feb 25, 2011 at 03:01:11PM -0500, John Baldwin thus spake: >On Friday, February 25, 2011 1:00:19 pm jhelfman@e-e.com wrote: >> > On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote: >> >> >> >> Read up on the mergemaster manual for options "-F" and "-i" :-) >> > >> > freebsd-update does not use mergemaster, though probably it should. >> >> My understanding is that freebsd-update was introduced prior to releases >> being branched, so this issue surfaced at that time. The patch I believe >> would be a fix to the freebsd-update client to better handle the tag. I >> can't see mergemaster as being an easier solution, as the actual binary >> would need to be verified against a known good index that would exist on the >> update server. > >No, release branches long pre-date freebsd-update. However, before we >switched to svn for source, new branches did not bump all the $FreeBSD$ tags. >That is a side effect of the way that the SVN -> CVS exporter works (and >arguably a bug). Yes. This is what I was trying to explain. Thanks for clearing this up, John. > >BTW, I did design etcupdate to support this sort of use case (you can build a >tarball from a given release tree and use that as the basis for comparisons >assuming you were bootstrapped to use etcupdate). Currently freebsd-update >doesn't use etcupdate and the author doesn't have any interest in changing it >to do so. Speaking as an administrator of my own set of freebsd-update-servers, I would suggest a different path to solve the issue. I am not certain what the exact path would be, but let me attempt to explain the issues I believe would come up. The freebsd-update-server software builds binary updates for distribution using that are updated using the freebsd-client off of an actual distribution iso that is built using the standard 'make release' process. So in edition to modifying the freebsd-update-server code to not build this portion of the release, or at least not distribute it, the client would need to be aware not to look for it, as well. You can update the client to use a different method for updating /etc, however the freebsd-update mirror servers will still be distributing the files, so you will have either a similar issue, or a new issue. Using the freebsd-update-software, I am not only able to apply security patches that are distributed by the security team, but I can also apply patches to /etc, or any part of the release for that matter, when it comes to distribution of updates from my updates servers. This is the flexibility I enjoy, and celebrate, in using FreeBSD. All of this being said, if an update software, and respective client were created specifically for /etc, it would be great to have similar functionality, in building off of a distributed iso, with the possibility of patching available, so this functionality is not lost. In addition to this, also using keyprints to authenticate the client, and distribute in a similar matter. I am copying Colin on this, in case he has any thoughts on the matter, or ideas that may make this a possibility. > >At some point if I have some time to hack on freebsd-update to be more useful >for modified versions of FreeBSD (e.g. building snaps from tags in an SVN >repository instead of a directory of patches against a CVS checkout), I will >probably hack it to support using etcupdate to manage /etc updates as well. > This would be great, if you can have it build and work off of a distributed iso. It would be very disappointing to be restricted to an svn/cvs tag/branch from FreeBSD, without the flexibility that is possible now using the freebsd-update-server software. This flexibility allows me to distribute binary updates for a custom kernel, and to modify /etc and distribute it at my leisure. >(etcupdate uses something akin to 'svn up' to update files in /etc, so things >like $FreeBSD$ changes just auto-update assuming they don't result in merge >conficts.) > >-- >John Baldwin > Thanks, and would enjoy being in on any future development thoughts, or ideas regarding your work on this. Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5