Automatically clean builds with old statefile formats

[ryandesign (Ryan Carsten Schmidt)]

Replying to cal@…:

The only situation where this can still happen is if the build was started before the update to 2.1.3 (thus still using the old statefile format), since we can't remove support for the old statefiles from base at the moment and unconditionally re-start every build still using the old statefiles.

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.

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.

I would like to ​rebuild all binary archives for MacPorts 2.2; perhaps if we do that, we can then make this change in MacPorts 2.2.1.

[neverpanic (Clemens Lang)]

Replying to ryandesign@…:

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.

We 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.

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.

From what I understood (and I haven't actually checked the code for that) the binary archives work by shipping a statefile and MacPorts picks up after the last action the statefile lists as done. I'll need to have a look at the relevant base code for this case, but if it was easy to drop support for the old statefile format I'd have done it.

[cooljeanius (Eric Gallager)]

Cc Me!