Re: make replace

[George Georgalis <george%galis.org@localhost>]

On Mon 05 Jul 2010 at 03:23:42 PM +0200, Dieter Baron wrote:
>
>  Which raises the questions: What temporary inconsistencies do we
>want to allow, how do we mark them, how do we handle them while
>operating on an inconsistent tree, and how do we detect that the tree
>is consistent again.

I think make replace / pkg_rolling-replace is a valuable time saver,
at first I was reluctant to use it because of the uncontrolled aspect,
but given the time saved and the risk of breakage, I use it and
address problems when they actually do come up.

For sites that require more reliability, isn't the answer "test" then
"deploy"---generally I do that by rebuilding and verifying /usr/pkg
offline then replace the production /usr/pkg with the new build and
restart services.

If the question of this thread is how to do an update (replace) in
a more reliable and seamless way, great, supporting (multiple) user
requirements of (multiple) software versions is the most difficult
aspect of sys admin, in my opinion. When it gets tricky, I will
typically put version numbers of software in the install path, but
that is a mess.

Perhaps a solution to addresses minimal downtime while doing more to
keep the packages consistent would narrow the gap?  If there was a
"quick-update" target that follows pkg_rolling-replace logic, by
building first, only instead of using the replace target does an
uninstall followed by an install, wouldn't that be a lot easier and
go a long way toward a better make replace?