On Jul 8, 2019, at 07:34, joerg van den hoff wrote:
> On 08.07.19 14:27 , Ryan Schmidt wrote:
>
>> I don't think MacPorts will uninstall a port unless you tell it to (directly
>> by name@version_revision+variants, or using a pseudoport (like "inactive" or
>> "leaves"), or using port(1)'s "-u" flag).
>> What could happen, though, is that MacPorts might deactivate a port if
>> another port has replaced its functionality. For example, if a port
>> texlive-old no longer exists but a port texlive-new now provides the same
>> files that texlive-old used to, then when you install or upgrade
>> texlive-new, it will automatically deactivate texlive-old. The result should
>> be that the files you want are still there. If somehow that didn't end up
>> being the case, you could reactivate texlive-old.
>> If you selectively update ports, you can run into situations where some of a
>> port's dependencies have been updated but others haven't. This can result in
>> a variety of problems, possibly including the one you mentioned. For this
>> reason, we recommend using "sudo port upgrade outdated" to upgrade all of
>> the outdated ports at once, and not selectively upgrading ports.
>
> OK, understood. I can confirm that the problem arose after issuing `port
> upgrade texlive' rather than doing a full upgrade of all outdated packages. I
> was not aware that this is (or might be) insufficient to get the respective
> package fully upgraded (including _all_ dependencies).
I agree that "sudo port upgrade texlive" should work for upgrading texlive and
all of its dependencies. However, any other installed ports might then be in a
non-working state. "sudo port upgrade outdated" should return those other ports
to working condition.
