tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Introducing the patchadd binary patch toolchain

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 -- 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,

Home | Main Index | Thread Index | Old Index