Easy access to external repositories.

[René J.V. Bertin]

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.