Portupgrade Operation

[Andrew Pantyukhin]

On 3/8/06, Chris Maness <chris at chrismaness.com> 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.