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: Matthias Schmidt <schmidtm@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 16 Dec 2007 13:41:26 +0100

Hi Simon,

* Simon 'corecode' Schubert wrote:
> [Just some comments, not meant to shoot you down]

No problem :)

> Matthias Schmidt wrote:
> > /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 :)

Yeah, bug is already fixed.

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

Thats right, but I'm a fan of saving disk space and bandwith.  Distributing
complete binaries has one big advantage.  We could update user-modified
binary files which is not easily possible with diff/pach. 

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

Yep, that's what the problem is about.

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

Do you mean with or without patching?

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

Sure, that's the reason why I posted the code and my thougts to the list

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

Why?  Most admins don't even have sources installed.  If someone wants
only a (security) fix I think its sufficent to update only the relevant



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