On Mar 15, 2021, at 08:45, René J.V. Bertin wrote:
>
> Hmmm, then I don't understand why yesterday this didn't work for me. Trying
> now with (an older version of) paracode as in your example gives a similar
> result. In my case however:
>
> {{{
>> sudo port activate paracode
> ---> Computing dependencies for paracode
> The following dependencies will be installed: python38
> Continue? [Y/n]: y
> Error: Requested variants "+readline" do not match those the build was
> started with: "+optimizations+readline".
> Error: Please use the same variants again, or run 'port clean python38' first
> to remove the existing partially completed build.
> Error: See
> /opt/local/var/lnxports/logs/_opt_local_linux-ports_lang_python38/python38/main.log
> for details.
> Warning: Failed to execute portfile from registry for paracode @2.7_0
> }}}
>
> I'm guessing an attempt would have been made to install python38+readline if
> I had not left the workdir around.
Sounds like it.
> Is it possible that no attempt is made to activate the port if it is already
> installed? I think you could argue that `port activate` should only do an
> actual install if the dependency is not installed at all. Otherwise you could
> end up installing a too-new version.
There is no such thing as a "too-new version". There is only one version of a
port available in the ports tree -- the current version.
If you install a port, MacPorts will first install or upgrade any of that
port's dependencies. The only exception is if you have the current version
installed but have then deliberately re-activated a previous version. In that
case, MacPorts assumes you have done that for a reason and are prepared to
accept the consequences and does not re-activate the current version.
I assume that MacPorts handles re-activation of a port the same way that it
handles installation of a port with regard to upgrading dependencies.
> PS: the port I tried this with yesterday is one of my own, a subport to which
> I added a runtime dependency on the main port and then reinstalled with
> `upgrade --force`. Maybe that somehow explains why it seems to ignore that
> new runtime dep?
Have you run portindex in the root of that ports tree, such that the
newly-added dependency is in the index? If not, that might explain it.
