DragonFly users List (threaded) for 2007-12
DragonFly BSD
DragonFly users List (threaded) for 2007-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Binary Updates for DragonFly

From: "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>
Date: Sun, 16 Dec 2007 13:25:52 +0100

[Just some comments, not meant to shoot you down]

Matthias Schmidt wrote:
> bspatch/bsdiff
> To use the client and the server tool you have to install Colin
> Percivals bsdiff/bspatch tools at first.  I have a version ready for
> DragonFly here:

should probably be placed in pkgsrc.

> Design and Implementation
> The server tool (gen_update.sh) basically compares two DragonFly
> "installations".  The first one is the original one, the second the
> modified one.  I populated two directories with "make installworld" and
> changed the "ls" binary in the modified one.

> /etc/named/etc/named is linked to ".." so the tool got stuck in an
> endless loop.  Removing the link temporary fixed that problem :)

You shouldn't recurse into symlinks :)

> The client checks if the server is available and fetches the INDEX file
> as well as the INDEX checksum.  If the checksums matches, all listed
> patch files will be fetched.  The original files will be patched,
> validated and stored for later installation.  If the user decides to
> install the patched files, the client will copy them to their locations.

I wonder, why bother with binary patches?  Network is cheap nowadays, so
we could as well distribute complete binaries.

> There are some areas needing improvement.  What to do about a self-build
> kernel/world with custom compiler flags etc where the checksums don't
> match?  freebsd-update (in its early days?!?) only supported the GENERIC
> kernel and worked only with a binary distributed userland.  I think most
> server admins also stick with the GENERIC kernel (at least I do it), so
> support for GENERIC would IMO be enough.

As soon as you compile stuff, you probably will get different binaries.
If you update the kernel, you need to update the userland as well.

If we had a way to identify from which sources a binary was compiled
from, we could do upgrades more easily.  Maybe enhance gcc to include a
checksum of the sources into the object?

In general I think this is a very worthwhile and necessary project, but
I see the problem space not yet completely explored :)

In any case, when doing a binary upgrade, we should at the same update
the sources, if installed.


Attachment: signature.asc
Description: OpenPGP digital signature

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