[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
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.
Main Index |
Thread Index |