Date: Sat, 26 Feb 2011 18:55:12 -0800 From: Jason Helfman <jhelfman@e-e.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-stable@freebsd.org, cperciva@freebsd.org Subject: Re: 8.2/7.4-RELEASEs Announced... Message-ID: <20110227025512.GA64170@eggman.experts-exchange.com> In-Reply-To: <201102251501.11318.jhb@freebsd.org> References: <4D66CCFF.9020903@buffalo.edu> <20110225160109.GA32260@lava.net> <20110225180019.GD76063@eggman.experts-exchange.com> <201102251501.11318.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110227025512.GA64170>