On Monday June 01 2015 16:57:39 Artur Szostak wrote: > > Did you handle deactivation or did you simply make it impossible. > > The update of the configuration files is handled during the activation phase > and rolled-back during deactivation. > So it should all be handled. Deactivating the port should get you back to the > same state as if the port was never installed in the first place. If this is > not the case then I should fix it :-) > Of course, a user could always break something by making some very weird > modifications to the configuration files directly. But I think I have handled > all reasonable scenarios.
Yeah? How do you handle %> port install repositoryA %> port install repositoryB %> port deactivate|uninstall repositoryA Do you roll back to the state from before installing repo A, removing repo B at the same time? That's just the easiest case, there are probably more complicated scenarios where the user didn't touch any configuration file directly ... > OK, so add-port-repository would ship with the MacPorts core? Not necessarily, it could be installed through a port itself (cf. port-depgraph or port-whatsnew, http://svn.macports.org/repository/macports/contrib/port-whatsnew). > Are we still talking about the same thing? I was thinking that implementing > the SAT-solver based solution might take a while. Ah, the general implementation of that, sure, that's possible. I was just talking about the implementation of per-port priorities on top of the current (or revamped) per-repo priorities. And I could be wrong :) R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
