Subject: Re: CVS commit: pkgsrc/net/mtr
To: NetBSD Packages Technical Discussion List <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 10/26/2001 17:59:33
[ On Friday, October 26, 2001 at 10:32:02 (+0200), Alistair Crooks wrote: ]
> Subject: Re: CVS commit: pkgsrc/net/mtr
> That's a good precaution, given that you have more than one of the
> same architecture. Using one of the more esoteric platforms for
> routers or mail servers is another precaution I take. And removing
> perl from DMZ hosts is another. Now do you see why I don't want
> perl, m4 et al dragged into the build?
There are risks to your "precautions".
I won't ever put a box into production unless I have another similar box
on which I can build and test software that I might need to use to
update the production server(s). That rule holds for my own personal
home machines, and for all the "real" production machines at my client's
Besides the benefits of being able to do isolated development and
integration testing there's also the benefit that if my production box
dies a horrible and complete death then the development box can be
pressed into service much more quickly than I could rebuild from scratch
on some other system.
Personally I'd suggest that if you don't have a separate box of similar
architecture on which to do deveopment and testing then you should at
least choose an architecture that's supported by the binary releases and
forget about trying to build and test your own software for your
production server(s). :-)
In the worst case though you can still make binary packages of the
development tools and just de-install them (and maybe even store them
off-line) when they're not being used.....
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>