Wisdom of automating upgrades
wmoran at potentialtech.com
Tue Jun 8 09:30:05 PDT 2004
Peter Risdon <peter at circlesquared.com> wrote:
> Bill Moran wrote:
> >Peter Risdon <peter at circlesquared.com> wrote:
> >>cvsup'ing overnight is routine and fine.
> >>The make build/install stuff seems a bit more delicate. I'm happy that I
> >>have figured out how to automate this, but not _whether_ I should do so.
> >>I am of course only considering tracking RELENG_4 at this stage.
> >Why not just cvsup/buildworld/buildkernel nightly, and monitor the FreeBSD
> >security advisory list. When a security problem is found, you only have to
> >installworld/installkernel, which is usually pretty quick.
> Yes, it is. That's a good compromise.
Watching the other posts, I would suggest another compromise as well: track
RELENG_4_10, not RELENG_4. Much more conservative commit policy.
When (if?) 4.11 comes out, you should expect a careful, manual switch from
the RELENG_4_10 branch to the RELENG_4_11 branch. I've been doing this since
4.7? and have had very few problems. But, occasionally, there are significant
changes between a point release.
> >>Ports are perhaps more likely to be problematic (though less likely to
> >>be a blocker to remote fixing than a failure to boot).
> >Install portaudit, which will include nightly audits of port problems in your
> >daily run email. This takes the guesswork out of when to upgrade. By cvsupping
> >the ports nightly, you only have to run portupgrade to get things updated.
> >Because of the dependencies in ports (which can get rather complex) I wouldn't
> >recommend automatically doing much with ports.
> If something in the dependency tree is broken or is imperfectly handled
> without manual intervention, the upgrade process stops short of
> deinstalling the existing port.
I _was_ going to comment on this, but you beat me to the punch ;)
This is a fantastic feature of portupgrade, which makes the package an
> A more severe problem would occur when a configuration file format
> changes, or there's deprecation and replacement.
This is the greater concern, and one that I doubt if portupgrade can address.
This bit me not too long ago, because of the migration of a lot of ports to
rcng ... without a <portname>_enable="YES" line in /etc/rc.conf, a lot of the
ports I upgraded didn't start after upgrading. Not a big deal, but a subtle
warning to be careful of config changes in ports!
> Perhaps I should say I'm pretty sure full automation would be unwise.
I agree. As I said before, big companies don't even automate the Windows Update
process, because (despite Microsoft's claims) doing so has bit them in the past.
> isn't unobvious and if it hasn't yet been done there's probably a reason
> for it. I'm trying to get a handle on what that is and to what extent
> solutions such as the one you suggested above can be used.
Good luck. I highly recommend portaudit! At least you know when it's time to
More information about the freebsd-questions