Unexpected clean

[Joshua Root]

On 2014-9-9 23:52 , Adam Dershowitz Ph.D., P.E. wrote:
> 
> 
> On Sep 9, 2014, at 9:43 AM, Brandon Allbery <allbery.b at gmail.com
> <mailto:allbery.b at gmail.com>> wrote:
> 
>>
>> On Tue, Sep 9, 2014 at 9:27 AM, Adam Dershowitz Ph.D., P.E.
>> <dersh at alum.mit.edu <mailto:dersh at alum.mit.edu>> wrote:
>>
>>     I do understand why the behavior happened, and I am not sure of
>>     the best solution going forward.  Perhaps, when doing upgrades due
>>     to “scanning binaries for linking errors” macports should honor
>>     the full command line?  I did tell it not to upgrade
>>     openmodelica-devel, and it did it anyway.
>>     Is there anything that I could have done differently (other then
>>     not using -u?)
>>
>>
>> If openmodelica-devel was rebuilt by rev-upgrade, it was because it
>> was affected by a link error. As such it would have been rebuilt
>> unconditionally, and by necessity to the latest version. I can't speak
>> to applicability of -u to rev-upgrade.
>>
>> In cases like this you might want to disable the automatic
>> rev-upgrade. That said, the fact that it was rebuilt does mean that
>> the old version *was broken* by some other upgrade. You may need to
>> block upgrades of dependencies in order to keep the older version
>> functional.
>>
>> -- 
> 
> 
> The difficulty, from a user perspective, is that it is not obvious when
> this kind of case will occur.  I saw that I had some outdated ports, and
> did an upgrade of outdated and not openmodelica-devel.  The difficulty
> is that one of those ports was omniORBpy which is what would have
> “broken" openmodelica-devel and caused the rev-upgrade.  This is not
> something that would have been obvious beforehand.  And also, is not a
> problem by itself.  
> The problem is that “-u” got passed to this rev-upgrade so during that
> process, all the old ones were deleted.  The idea that "sudo port -u
> upgrade outdated and not openmodelica-devel” will not only upgrade
> openmodelica-devel but also delete all the old version of that specific
> port seems like a trap to users.  

There probably isn't a good solution for your use case without adding
version pinning. Generally, I don't see rev-upgrade upgrading the port
when it's broken as being a problem. Broken ports are no good to you.
Uninstalling all the old versions without being (directly) told to is
bad though. If that didn't happen, you could still restore the "broken"
version by activating it along with its correspondingly old dependencies.

- Josh