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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
