Re: Introducing the patchadd binary patch toolchain

[Terry Moore <tmm%mcci.com@localhost>]

At 04:51 PM 4/29/2009 -0400, Steven M. Bellovin wrote:
> On Wed, 29 Apr 2009 16:41:07 -0400 (EDT)
> der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
>
> > > The lack of binary patches is a major deficiency in NetBSD.
> >
> > It is also a major asset, and everything in between.
> >
> > Where on that spectrum it falls for any particular person depends on
> > that person's goodness metric.  Not everyone shares your point of
> > view.
> >
> If the choice were binary-only or source-only, I'd definitely pick the
> latter.  If the choice were TNF-built binary patches vs. home-build
> source, again I'd pick the latter.  But if I'm running many machines, I
> want an easy way to ship out binaries, whether I choose to use ones I
> build or the ones that TNF will (presumably) provide.  Source-only just
> doesn't scale very well, especially for tiny machines.

I hesitate to comment, but ....

The word "patches" prejudges how the solution is delivered to the 
end-node; would not "update" be better, as it doesn't pre-judge how 
the migration will be achieved?

Terminology aside, there are perhaps several issues here:

1) userland -- can be updated by binary updates of entire file(s); or 
can be updated by patches, if you know what version was there before.

2) generic kernels (or generic.mp) -- can be updated as in #1.

3) custom kernels -- must be updated by delivering source updates (or 
patches) and rebuilding.

It seems to me any patch infrastructure is going to require that 
sysadmins adhere to centrally dictated standards -- if things aren't 
"in the right place", then the automated utility will get confused.

Given that, the project could define an "updatable config" -- which 
has to include a sysdamin who is willing to accept updates according 
to the policy of the update distributor.  (I.e, if the sysadmin opts 
out, that doesn't mean they're bad, it just means they don't get 
automatic updates from the distribution system.)

With an updatable config:

1) all userland utilities could be updated automatically

2) users with standard kernels can receive kernel updates automatically

3) Users with custom kernels, and with their kernel sources on each 
machine in a standard place, can receive automatic source updates for 
custom kernels (and rebuild at their leisure).

Users who don't have an updatable config probably have the judgement 
and ability to get what they need from CVS.

As for accepting (or not accepting) individual updates -- most 
maintainers of binary distributions are not going to want to support 
the full tree.  If I accept update #1 for ls, refuse update #2 for 
ls, and then want update #3 for ls, few distributors will be willing 
to create (and verify) the version of ls that has updates 3 and 1, 
but not 2.  Most likely you'll get 1 and 2 if you get 3.  Perhaps not 
a problem, as people have source access.

Of course, this would probably be better accepted if I were 
volunteering to do any of the work.... but this kind of architectural 
discussion still may be helpful, I suppose.

Best regards,
--Terry