Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Jun 2004 17:19:43 +0100
From:      Peter Risdon <peter@circlesquared.com>
To:        Bill Moran <wmoran@potentialtech.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Wisdom of automating upgrades
Message-ID:  <40C5E71F.6010702@circlesquared.com>
In-Reply-To: <20040608102534.63e0259b.wmoran@potentialtech.com>
References:  <40C5BCAC.6090401@circlesquared.com> <20040608102534.63e0259b.wmoran@potentialtech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Bill Moran wrote:

>Peter Risdon <peter@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.


>>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. Otherwise, the thought of automation 
wouldn't have crossed my mind. Of course, the time spent tidying up such 
situations might outweigh the time saved.

A more severe problem would occur when a configuration file format 
changes, or there's deprecation and replacement.

Perhaps I should say I'm pretty sure full automation would be unwise. It 
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.


Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40C5E71F.6010702>