8.2/7.4-RELEASEs Announced...

[Jason Helfman]

On Fri, Feb 25, 2011 at 03:01:11PM -0500, John Baldwin thus spake:
>On Friday, February 25, 2011 1:00:19 pm jhelfman at 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