tech-userlevel archive

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

Re: Having an integrated system update mechanism


> for GSoC, I wrote two scripts: sysupdate(8) and sysbackup(8) for
upgrading and
> backing up a NetBSD system [1]. They resemble the function of 
> freebsd-update(8) from FreeBSD, you can fetch them from [3]. 
> Anyway, there has been an alternative right from the beginning on,
> named sysupgrade by jmmv [2] (which is also in
> pkgsrc/sysutils/sysupgrade), which is already tested and in use. So
> I'm asking for you to review my code (just watch out for [4]) and
> to propose what should be changed, which one of these two should be
> taken or why they are both unsuitable.
> My arguments for sysupdate instead of sysupgrade are: * sysupdate
> can check whether updates are necessary at all * sysupdate can
> check what will be changed * sysupdate will check hashes and
> signatures * sysupdate resembles the use of freebsd-update(8) more
> closely * sysupdate can do backups with sysbackup
> What I have to admit (I hope jmmv will jump in here): * sysupgrade
> is much simpler * sysupgrade has tests * sysupgrade is better
> tested
> I could just push my own one to pkgrsc, but I think, NetBSD must
> have an upgrade mechanism included, and I would like to import
> either of these two to base.

First, I admit that I did not look closely at either solution, so I
will not comment on the technical fitness or non-fitness of either.

I also do think that NetBSD should have an included update mechanism
that works nicely and is well tested.  Imo, it should be possible to
reboot into a new kernel, install a new system, reboot, update binary
packages, all automated an unattended, with a report via email if
thinks went ok or not.

Why don't you try to merge the two existing solution and take the best
from either?

> Regards, Julian
> [1]: 
> [2]: [3]:
> [4]: You will see the command `test
> $arg1 -fn $arg2`, which just does an fnmatch(2) of arg1 against
> arg2 and arg2 against arg1. The patch to test(1) is about adding 10
> lines to test.c, or we could also create an additional binary
> achieving the same effect.

Home | Main Index | Thread Index | Old Index