I expect this post to be a non-starter, but at the very least, it’s a place to perhaps discuss whether there may be workarounds. I’m not counting on it, though.
Around three months ago, a port upgrading of outdated components on my 10.14.6 daily driver failed when several ports failed to update — whether as 'upgrade outdated' or 'upgrade [port]'. I thought the culprit was something I might have done in previously, such as having installed another component with variants which propagated update-build problems for other ports down the line.
Perhaps — no, definitely — unwisely, I proceeded with a completely fresh install of macports on that Mac, rebuilding the binaries and GUI-based applications I rely on. On that particular day, I was planning to use gqrx in the field later that evening. That opportunity never came.
gqrx, as with many other GUI-based ports, relies on the Qt5 framework. Each new build attempt, as with the upgrade attempts I made before wiping clean the slate, kept halting on either of two, but interrelated Qt5 dependencies: qt5-qttools 5.15.15 and qt5-qtconnectivity 5.15.15. There was no way around it, no variants to remove to simplify the build, nothing. Arising from this, I withheld all selfupdates and upgrading of outdated components on my 10.13.6 boxes, leaving all in a holding pattern until this issue was resolved. This includes security stuff. (Yes, one could manually upgrade individual ports, but when there are hundreds or even more ports installed, this obviates the whole purpose of the “outdated” syntax. Moreover, it doesn’t enable me to return gqrx to my 10.14.6 box.)
Eventually, I found an open, still-new (at the time) macports ticket with a couple of users posting logs displaying a failure to build either of the two dependencies across multiple macOS builds (and, again, upon which other GUI-based ports rely).
Since then, a dozen more updates by other users sharing their errors (every one is the same) have added to the ticket. There does not appear to be a priority to resolve the build failure, leaving scores of Qt5-dependent applications stuck. Because the ticket isn’t closed (signalling this is where 10.13.6, 10.14.6 and possibly other macOS builds get left behind), I’m optimistic there will be a fix (whether with a 5.15.16 update from the Qt5 maintainers, or with a patch by the macports team). Until then, I’m without a dozen or so applications which require Qt5, as least on that Mojave box, while the others are being held from updates.
My question: has there ever been a way to direct macports to build from a snapshot of repositories from an earlier date, even should that mean having to install a date-appropriate earlier version of macports itself? (Currently on 2.10.4, but current at the time was 2.10.1.)
My guess is no, given how versions of tarballs on the mirrors seem to roll with updates, with typically only the last one or two revisions behind the current version present. Nevertheless, the harm in asking is low. Unlike the macports TracReports open ticket system, there’s not really a way to ask this question there.
Cheers.
Around three months ago, a port upgrading of outdated components on my 10.14.6 daily driver failed when several ports failed to update — whether as 'upgrade outdated' or 'upgrade [port]'. I thought the culprit was something I might have done in previously, such as having installed another component with variants which propagated update-build problems for other ports down the line.
Perhaps — no, definitely — unwisely, I proceeded with a completely fresh install of macports on that Mac, rebuilding the binaries and GUI-based applications I rely on. On that particular day, I was planning to use gqrx in the field later that evening. That opportunity never came.
gqrx, as with many other GUI-based ports, relies on the Qt5 framework. Each new build attempt, as with the upgrade attempts I made before wiping clean the slate, kept halting on either of two, but interrelated Qt5 dependencies: qt5-qttools 5.15.15 and qt5-qtconnectivity 5.15.15. There was no way around it, no variants to remove to simplify the build, nothing. Arising from this, I withheld all selfupdates and upgrading of outdated components on my 10.13.6 boxes, leaving all in a holding pattern until this issue was resolved. This includes security stuff. (Yes, one could manually upgrade individual ports, but when there are hundreds or even more ports installed, this obviates the whole purpose of the “outdated” syntax. Moreover, it doesn’t enable me to return gqrx to my 10.14.6 box.)
Eventually, I found an open, still-new (at the time) macports ticket with a couple of users posting logs displaying a failure to build either of the two dependencies across multiple macOS builds (and, again, upon which other GUI-based ports rely).
Since then, a dozen more updates by other users sharing their errors (every one is the same) have added to the ticket. There does not appear to be a priority to resolve the build failure, leaving scores of Qt5-dependent applications stuck. Because the ticket isn’t closed (signalling this is where 10.13.6, 10.14.6 and possibly other macOS builds get left behind), I’m optimistic there will be a fix (whether with a 5.15.16 update from the Qt5 maintainers, or with a patch by the macports team). Until then, I’m without a dozen or so applications which require Qt5, as least on that Mojave box, while the others are being held from updates.
My question: has there ever been a way to direct macports to build from a snapshot of repositories from an earlier date, even should that mean having to install a date-appropriate earlier version of macports itself? (Currently on 2.10.4, but current at the time was 2.10.1.)
My guess is no, given how versions of tarballs on the mirrors seem to roll with updates, with typically only the last one or two revisions behind the current version present. Nevertheless, the harm in asking is low. Unlike the macports TracReports open ticket system, there’s not really a way to ask this question there.
Cheers.
