port upgrade outdated order

[René J.V. Bertin]

On Wednesday March 04 2015 18:52:27 Mihai Moldovan wrote:

> Probably because it has never been implemented. Patches welcome, I
> guess?

Probably requiring more knowledge of the internals than I currently have ...

> Also, you'd have to make sure that foo-B builds correctly or, if
> it fails, activate foo-A again after it failed. I don't know whether
> MacPorts base can do this. I doubt it does.

No, I think it can't. However, if a conflict is not a build conflict the deactivation could be done very late, even after foo-B's archive has been unpacked in the temp. directory in ${prefix}/var/macports/software/foo-B . At that point you can be pretty sure that everything will be fine.

BTW, I've already raised a suggestion recently that the same thing could be done while doing an upgrade (or reinstall through `port -n upgrade --force foo`), to reduce the time that the system spends without any active version. 

> > (just to be sure, if you declare a path: style dependency, the
> provided path is recorded in the registry, right?)
> 
> No, why? The path-based dependency is not part of the portfile that
> provides it, but some other, unrelated one.

No, not of the port that provides the path of course. I meant, if foo depends on path:lib/libbar.dylib:bar, what gets registered? I'd guess lib/libbar.dylib and not port:bar, because otherwise I don't see how you could use this mechanism to depend on either port:bar or port:bar-devel or whatever.

R.