Darren Spruell wrote:
On 8/25/07, Clint Pachl <[EMAIL PROTECTED]> wrote:
The reason for this is that I can use a single build machine running the
current release, and two source trees, current and previous.
[1] Well, it usually does, but it can break in interesting ways that are
difficult to fix.
Joachim, your footnote is what I was expecting to hear. After running a
few tests, I have been able to compile 4.0 patches on a 4.1 system, but
I'm sure I will run into edge cases that crap out sooner or later. I
guess I will mark this up as an unreliable operation.
Thanks for your suggestions. I think a dual-boot machine will be the way
I'll go.
Are you talking about many 4.0 systems? In your place, I might simply
opt to push for upgrades to 4.1 as it would be about as simple and
easy as dual boot to build patches. This crazy guy
(http://erdelynet.com/tech/openbsd/quick-upgrade-process/) clocks 20
minutes start to finish.
About 20 boxes. The thing is that I cannot upgrade all boxes at the same
time. They need to be scheduled in non-interrelated groups to ensure
services will not be affected, or affected as little as possible.
I was just asking about the instance where a patch is released while I'm
in the middle of a network upgrade where I have some boxes at the newest
release while others are still running the previous release. My build
box is the first box to get upgraded. So I was wondering if I could
build previous release patches, using previous release source of course,
on a current release system?
The situation I'm describing is kind of a rare occurrence. The
alternative is I could just leave the previous release boxes unpatched
for a few days to a couple of weeks until they are upgraded to the next
release. I'm not sure if that is a good idea though. I guess it depends
on the severity of the exploit.
In a couple of months your 4.0 will no longer be supported anyways.
Yes, I know. I'm slowly getting everything to 4.1. I've been slacking.
It's tough to upgrade when everything is running so smoothly!
-pachl
