[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
> backing up a NetBSD system . They resemble the function of
> freebsd-update(8) from FreeBSD, you can fetch them from .
> Anyway, there has been an alternative right from the beginning on,
> named sysupgrade by jmmv  (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 ) 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
> 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
> Regards, Julian
> : http://www.komkon2.de/dokuwiki/doku.php?id=blog:gsoc_is_over
> : https://github.com/jmmv/sysupgrade :
> http://komkon2.de/sysupdate.tgz : 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.
Main Index |
Thread Index |