On Mon, Jan 20, 2014 at 3:20 PM, Ryan Schmidt <[email protected]> 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 deactivat ed. > > 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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
