<div dir="ltr">Sounds kind of like the "sensible alternatives" approach that many dpkg-based package managers take: <a href="https://packages.debian.org/unstable/sensible-utils" rel="noreferrer">https://packages.debian.org/unstable/sensible-utils</a><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 8:02 AM, Mojca Miklavec <span dir="ltr"><<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
for Python ports it makes sense not to install "python" to $prefix/bin<br>
because that would shadow the python which comes with the system.<br>
<br>
What about if we currently ship a certain port that installs the<br>
binary to $prefix/bin and would like to allow parallel installation of<br>
a newer (experimental) version. In order to prevent conflicts the<br>
binaries should no longer end up in $prefix/bin. But would it be<br>
possible/allowed to automatically run "port select <port_group_name><br>
<port_version>" after the first of two ports gets installed?<br>
<br>
That way the users would still get the expected binary in $prefix/bin<br>
when they first install the port. Those who want to play with both<br>
versions would still be free to do so by running "port select"<br>
manually at any time.<br>
<br>
Mojca<br>
_______________________________________________<br>
macports-dev mailing list<br>
<a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-dev" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-dev</a><br>
</blockquote></div><br></div>