On Feb 25, 2019, at 00:41, Mojca Miklavec wrote:
> This message tells you what precisely to do to work around the issue: > sudo port -f dectivate poppler > sudo port install poppler > > We usually do something like deactivate hack > https://trac.macports.org/wiki/PortfileRecipes#deactivatehack > but I don't know why it wasn't done this way (maybe it doesn't work, > maybe there were other reasons ...). As explained on the wiki page, we typically use the deactivate hack when a port now provides files that one of its dependents previously provided. Not doing so would result in activation failure, and we want to prevent users from experiencing that. That's not what's happening with poppler. Poppler has a build conflict with another port (coincidentally: with older versions of itself). In those cases, we don't use the deactivate hack; instead we notify the user of the problem by using the conflicts_build portgroup. The user can then take charge of deactivating the conflicting port before the build and reactivating it afterward. Or the user might choose to postpone the upgrade, if they happen to know that they need the conflicting port to remain active for the time being. Maybe the conflicting port is (or is required by) a server process that they want to keep running, or a utility that the user is using in a script. One could argue that we should handle both situations the same way. But the reason we handle them differently might be as follows: The deactivate hack is used when two related ports have reorganized which one of them provides which files. For example, netpbm used to provide a bunch of libraries, but I moved them to a separate libnetpbm subport, therefore I had to use the deactivate hack in libnetpbm to deactivate any already installed older copy of netpbm. One could argue that doing so makes netpbm temporarily unavailable to the user. But the most likely way for the user to encounter this situation is for them to upgrade netpbm, and if the user has consented to that, then they already expect the netpbm programs to be unavailable for a short time. In contrast, build conflicts are typically declared between unrelated ports. A user upgrading a port would most likely not expect an unrelated port to be automatically deactivated, even temporarily.
