On 3/8/06, Chris Maness <[EMAIL PROTECTED]> wrote: > I have been told that tracking the whole port tree on a production server > is a bad idea. I kind of agree thinking about the old addage "if it aint > broke don't fix it."
Arguably the best strategy for the base system. Arguably a bad idea in case of 3d party software. In most cases untested updates do not enter the ports tree. Just use the -b flag when portupgrading and go back if you meet a show-stopper. Lately we've been experiencing trouble with something as critical as quagga. That only caused a half an hour late night outage on a single server. We haven't had any trouble apart from that in a year. With hundreds of ports in production, we find it delicious to have them all so easily and seamlessly updated. > But, if a security issue becomes known with a port > that I have installed, I definately want to fix the issue. Your answere > definately confirmed for me how port upgrade works. > > It seems that other dependant ports would not have to be current on the tree > if > they were re-compiled allowing autoconf to establish the location of depended > files. However, it seems that portupgrade does not uninstall and re-compile > if > the dependant ports have not changed (ie the folder containing the ports > make file and patches), it only recompiles parts of the tree > that have been upgraded, and are linked via portupgrade -rR. > > It would be nice if portupgrade had a flag to do that (that is if my logic > is correct). -f > It would be nice if ports forked the way src does. Then I could just > track bugfixes and security issues. I'd say that you can hardly find an update which is neither. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
