On Jan 20, 2014, at 8:04, Adam Mercer <[email protected]> wrote: > >> On Sun, Jan 19, 2014 at 11:37 PM, Ryan Schmidt <[email protected]> >> wrote: >> >> This situation does not call for the deactivate hack; rather, it calls for >> the conflicts_build portgroup. (The port would declare a build conflict with >> itself.) > > But that would lead to the build failing without manual intervention, > i.e. manually deactivating the port.
Correct, if the user builds from source. If the user installs pre-compiled binary packages there would be no problem. Perhaps that is some consolation. > I'm trying to automate this so > users don't notice the problem. That would be nice but I'm not sure of a good way to do it. 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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
