On Nov 28, 2019, at 06:23, joerg van den hoff wrote:
> On 28.11.19 12:44 , Ryan Schmidt wrote:
>> On Nov 28, 2019, at 04:48, joerg van den hoff wrote:
>>> I ran `port upgrade outdated' today. after end of sucessfull completion
>>>
>>> `port outdated' still reported
>>>
>>> ghostscript 9.27_1 < 9.50_0
>>>
>>>
>>> rerunning the `upgrade' did not change anything. on further inspection I
>>> see that I now have
>>>
>>> 1) ghostscript @9.25_1+x11
>>> 2) ghostscript @9.26_0+x11
>>> 3) ghostscript @9.27_1+x11 (active)
>>> 4) ghostscript @9.50_0+x11
>>>
>>>
>>> question1: why does this happen? should not the `upgrade' take care of
>>> deactivating/activating automaticall? it usually does...
>> Yes of course. But it is possible for the activate phase of a port to fail.
>> I think that should leave you with *no* version active, rather than the old
>> version active. It is also possible for the user to reactivate old versions,
>> though I suppose you would know if you had done this.
>
> I don't think that has happened. if so, it would have to be too long ago to
> remember. so is that a potential bug in `ports' logic?
I really can't answer that at this point. If you have a reproduction recipe
that always leads to this problem happening, then we could investigate it.
