In the last episode (Oct 02), Thomas Mueller said: > How can one do a massive portupgrade, as with -r or -R, without being > interrupted by options configuration screens for many individual ports? > Idea is to let it run unattended such as when I might run it starting just > before bedtime. Doing "make config" ahead of time also gives the chance > to recover from a typo at the configuration screen (high risk). > > Best thing I can think of is, using multimedia/ffmpeg as an example, is > doing a dry run > > portupgrade -Rn multimedia/ffmpeg |& tee -a wouldbe.log > > This would show what other packages would need to be portupgraded and > avoid reconfiguring up-to-date dependencies. Then I would go to each of > those directories in the ports tree and run "make config". > > Running "make config-recursive" in /usr/ports/multimedia/ffmpeg would > produce configuration screens for all dependencies, including those that > are up-to-date.
config-recursive does a "config-conditional" for each dependency. It should only up a config dialog for an installed up-to-date port if the port maintainer has added OPTIONS lines without bumping the portversion. That should be a rare occurance. > I tried > > portupgrade -RCn multimedia/ffmpeg |& tee -a wouldbe.log The -c flag is what you really wanted, I think. -C reconfigures every port, while -c calls "make config-conditional". > but then I got all dependency configuration screens, including those that > were up-to-date, and also the interface didn't work right: I got garbage > when trying to respond; it didn't write to the configuration screen but > produced non-color garbage to the background. Probably because you tee'd the output, so all the child processes see is a pipe on stdout (and apps usually only try to do color and cursor positioning on ttys). With -n you're not building anything anyway, so there's really no need to log the output. Just run it without the tee, then run your regular portupgrade later with tee. Instead of using tee, I use /usr/bin/script, which gives child processes a real tty to interact with, so full-screen apps work correctly. -- Dan Nelson dnel...@allantgroup.com _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"