Changes between Initial Version and Version 1 of Ticket #38862, comment 1


Ignore:
Timestamp:
Apr 19, 2013, 11:22:44 PM (12 years ago)
Author:
neverpanic (Clemens Lang)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #38862, comment 1

    initial v1  
    22> I would actually be in favor of doing exactly that starting with MacPorts 2.2. It's probably best if any builds started with MacPorts 2.1.x or earlier are automatically blown away and restarted, given the several changes that have gone into trunk that affect many ports (change in default compilers (r102269); change in default optimization level (#38218); change in library header padding (#29838); no more library overlinking (#38010)). Since statefile version 2 appeared in MacPorts 2.1.3, I'd like to increase the statefile version to 3 before the release of MacPorts 2.2.
    33
    4 We can think about that, but we will get the same problem we had when switching from statefile format 2 to 3 – we can't just blow away all partial builds with an older statefile format, because afaik it would break the binary archives and re-activating previously deactivated ports.
     4We can think about that, but we will get the same problem we had when switching from statefile format 1 to 2 – we can't just blow away all partial builds with an older statefile format, because afaik it would break the binary archives and re-activating previously deactivated ports.
    55
    66> comment:ticket:29223:68 cites a problem with this idea, something about binary archives containing a statefile and therefore not being used if we were to make this change? This refers to the "+STATE" file I think? I guess I don't understand why that file is part of our archives or why MacPorts checks its contents.