> Looking at the MacPorts for submitting tickets, there is a suggestion to run > for " Is the problem with a 'port upgrade' operation?": > > " ... try a 'port uninstall foo' and then reinstall. You might also want to > run 'port -nR upgrade --force foo' to rebuild ports depending upon port foo". > ( i.e. port -nR upgrade --force ffmpeg')
Doing an uninstall gets rid of the locally stored binary, whether it's active already or not. If you have multiple versions installed then you'll need to use the "name @version+variants" fully qualified format, similar to what you see in `port installed ffmpeg`. The forced upgrade command effectively achieves this as well. > Is it OK in my case? I'm not sure if it will then provide the wrong info in > the log file. In the mean time I will wade through Chapter 7.1 > in"http://guide.macports.org/#project.tickets";. It's fine and won't hurt anything that isn't already reported broken. As you suspect, it will wipeout and reuse the log file. The real issue isn't that macports is simply installing a pre-built binary of ffmpeg (we cannot distribute the +gpl2 variant): it could, however, be a dependency installed with the wrong variants or +gpl2 might be assuming too much. Either way, the main issue is your local build of ffmpeg failed and subsequent build attempts (rev-upgrade tries a few times before giving up, or you manually trying to run another build) the logs weren't complete (it skipped previously completed phases). Each build attempt truncates the log. The skipped phases are rather instrumental as they may show other settings throughout all phases. Similarly, if build phase is run repeatedly it will likely skip already completed files. Having a clean build attempt includes all of this information in the log file. _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-users
