Unexpected clean

Adam Dershowitz Ph.D., P.E. dersh at alum.mit.edu
Tue Sep 9 08:00:07 PDT 2014



On Sep 9, 2014, at 10:12 AM, Daniel J. Luke <dluke at geeklair.net> wrote:

> On Sep 9, 2014, at 9:52 AM, Adam Dershowitz Ph.D., P.E. <dersh at alum.mit.edu> wrote:
>> 
>> 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.  
> 
> It's not entirely obvious what the 'correct' behavior would be, though.
> 
> Your new omniORBpy (upgraded with -u) is the only one available after the upgrade. The installed openmodelica-devel is now broken (won't work with the new omniORBpy). rev-upgrade /could/ ignore the -u and build a new openmodelica-devel to fix the issue for you, but you wouldn't be able to re-activate the old one and have it work.
> 
> I would suggest that what you actually want to be doing is something like:
> 
> port upgrade outdated
> port uninstall inactive and not openmodelica-devel (and maybe using one or more of the pseudo-portname selectors to also hang on to any old dependencies or dependents).
> 
> --
> Daniel J. Luke                                                                   


I completely agree that there is not an obvious “correct” answer.  I understand why it did what it did, and just wanted to put this issue to the community, but I don’t claim to have a single “solution”.  
What you suggested might be the best procedure to follow going forward.  

—Adam


More information about the macports-dev mailing list