I'm replying back to the mailing list because it's important for everyone to understand why we do what we do.
We use the deactivate hack when a port provides a file that was formerly provided by another port. This is fine because it happens at pre-activate time so there's only a small window of time where the files aren't on disk, so a user who relies on the files being there is more likely to find them there. And it's unlikely that the activate phase would fail. https://trac.macports.org/wiki/PortfileRecipes#deactivatehack We don't do this for build conflicts because we would have to deactivate the conflicting port at pre-configure time, so the files would be absent from disk for the duration of the configure, build and destroot phases. Depending on the port, that might take some time, and the user might notice the absence of the files. Worse, if any of those three phases fails, the files would permanently be absent, until the user manually re-activates the conflicting port. If the user isn't the one who deactivated it to begin with, the user may not know which port to re-activate, nor that they should do so. I think it's better to let the user be in control of deactivating and re-activating conflicting ports so they are not surprised. > On Jun 13, 2015, at 08:25, Jeremy Lavergne wrote: > > I thought we used deactivate hooks to avoid that problem and allow upgrades > to happen where possible. > >> On Jun 12, 2015, at 4:57 PM, Ryan Schmidt wrote: >> >> For ports that have build conflicts with other ports (like netpbm which has >> a build conflict with itself), we leave deactivating the conflicting port to >> you, > _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
