Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

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