Deactivating the installed version before trying to install the update

[Adam Mercer]

On Mon, Jan 20, 2014 at 3:20 PM, Ryan Schmidt <ryandesign at macports.org> wrote:

> That would be nice but I'm not sure of a good way to do it.

That's the conclusion I'm coming to as well.

> If there is a way to do it, you should do it in a way that all affected ports can benefit, not just yours. The way this scenario has been handled before is with the conflicts_build portgroup, so if you can improve the behavior, you probably should do so in the portgroup. However I don't know of a way to improve the behavior that doesn't have the potential for unexpected consequences.
>
> The deactivate hack is mainly for situations where a file that used to be provided by one port is now provided by another port and a dependency between them would cause an activation conflict during upgrades. For example, the file port used install both the file utility and the libmagic library it uses. Then the libmagic library was moved to its own subport and the file port was changed to declare a dependency on it. If a user had the old file-including-libmagic port installed, and tried to upgrade, MacPorts would first try to install the new dependency libmagic, but would fail to activate it because the files it wants to install are already there from the old version of the file port. So the libmagic port uses the deactivate hack, to deactivate the old file port right before activation. This is fairly safe because unless the activation of libmagic fails, there's no opportunity for the software the user uses (in this case the file utility or its library) to become deactivated.
>
> Your scenario is different. Your port fails to build if another version of itself is active. You propose deactivating the installed version before building. Depending on how long the port takes to build, this leaves a potentially long period of time during which the software the user uses is deactivated, and there's the potential, if the build or destroot fails, for the port to remain deactivated until the user manually intervenes, which would be unexpected.

Agreed, I think we're just going to have to bite the bullet and have
the users manually deactivate the port. Not ideal, but better than
unexpected behaviour.

Cheers

Adam