qca and subports: revisions have not been restored correctly

[ryandesign (Ryan Carsten Schmidt)]

qca and subports were updated in [a971437a4529e72ff8d619adfbeec7ac8ea7b3b2/macports-ports]

The update was reverted for some subports in [dad04b15bee6ca8f4d4f3e19ac1ed36c0e0282fb/macports-ports] but the port revisions were not returned to their previous values.

Before a971437:

$ port info --name --version --revision {,subportof:}qca
name: qca
version: 2.2.1
revision: 4
--
name: qca-cyrus-sasl
version: 2.2.1
revision: 0
--
name: qca-gnupg
version: 2.2.1
revision: 0
--
name: qca-ossl
version: 2.2.1
revision: 2
--
name: qca-pkcs11
version: 2.2.1
revision: 2
--
name: qca-qt5
version: 2.2.1
revision: 4
--
name: qca-qt5-cyrus-sasl
version: 2.2.1
revision: 0
--
name: qca-qt5-gnupg
version: 2.2.1
revision: 0
--
name: qca-qt5-ossl
version: 2.2.1
revision: 2
--
name: qca-qt5-pkcs11
version: 2.2.1
revision: 2

After dad04b1:

$ port info --name --version --revision {,subportof:}qca
name: qca
version: 2.2.1
revision: 0
--
name: qca-cyrus-sasl
version: 2.2.1
revision: 0
--
name: qca-gnupg
version: 2.2.1
revision: 0
--
name: qca-ossl
version: 2.2.1
revision: 0
--
name: qca-pkcs11
version: 2.2.1
revision: 0
--
name: qca-qt5
version: 2.3.4
revision: 0
--
name: qca-qt5-cyrus-sasl
version: 2.3.4
revision: 0
--
name: qca-qt5-gnupg
version: 2.3.4
revision: 0
--
name: qca-qt5-ossl
version: 2.3.4
revision: 0
--
name: qca-qt5-pkcs11
version: 2.3.4
revision: 0

Note how the subports qca, qca-ossl, and qca-pkcs11 now have lesser revisions than they used to. This must be corrected by increasing the revisions to the same value as before (if the ports install the same exact files as before) or higher than they were before (if the ports now install different files than before, for example if you are now linking with a different openssl version than before). (And the revisions of the subports whose revisions remained at 0 would need to be increased if they are now different than before.)

Also, the epoch was not increased. This might be ok: If the update to 2.3.4 was unbuildable for all users, then the epoch should not be increased. However if any users were able to install the 2.3.4 subports that you have now reverted to 2.2.1, the epoch must be increased, otherwise those users will not see the downgrade available in port outdated and sudo port upgrade outdated will not perform the downgrade.

[RJVB (René Bertin)]

Something is off here, maybe you missed an update?

• I did not change the revision numbers of the Qt5 subports, nor did I change the version which was already at 2.3.4
• The epoch of the Qt4 (v2.2.1) subports *is* changed, and the *upgrade* of their version (in the previous commit of this port) is REVERTED.

Here's the relevant hunk of the change (which may seem more invasive than it really is; I moved the version and checksum data around to keep the number of conditional blocks as low as possible):

@@ -11,10 +10,21 @@ subport ${name}-qt5     {}
 
 if {[string match "${name}-qt5*" ${subport}]} {
     PortGroup           qt5 1.0
-    set Qt_Major        5
+    set Qt_Major        qt5
+    version             2.3.4
+    checksums           rmd160  88589c5b4f2a87cb048b5a90ff39256ec996fdb1 \
+                        sha256  6b695881a7e3fd95f73aaee6eaeab96f6ad17e515e9c2b3d4b3272d7862ff5c4 \
+                        size    737072
 } else {
     PortGroup           qt4 1.0
-    set Qt_Major        4
+    set Qt_Major        qt4
+    # last release with Qt4 support:
+    version             2.2.1
+    # set the epoch because we've had to downgrade
+    epoch               202111
+    checksums           rmd160  dddc3cf240dc5424b9df13fc1bf41c8e04f3b814 \
+                        sha256  d716d2d8e3ed8d95bbdb061f03081d7d032206f746a30a4d29d72196f50e7b02 \
+                        size    691676
 }
 # best included after the required Qt PG
 PortGroup               cmake 1.1

port upgrade qca worked just fine for me (idem for qca-ossl and the other Qt4 subports). There was no reason to touch the revision of the Qt5 subports. Either they built before and would now build to exactly the same binaries, or they didn't build because of missing headers (cf #63980) and should now build. There's long-standing precedence of not revbumping (Qt5) ports in this scenario.

[mascguy (Christopher Nielsen)]

I pre-tested the PR on macOS 10.12 prior to merge, and the various changes - including epoch-related - seemed to work fine.

Haven't done exhaustive before-and-after tests on earlier macOS releases, but didn't notice any issues.

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

Something is off here, maybe you missed an update?

No.

• I did not change the revision numbers of the Qt5 subports, nor did I change the version which was already at 2.3.4

And I have no complaint about that.

• The epoch of the Qt4 (v2.2.1) subports *is* changed,

You're right, I missed that part of your update. Disregard what I wrote about the epoch.

and the *upgrade* of their version (in the previous commit of this port) is REVERTED.

Yes, but the revisions have not been restored to (or above) their prior values, as is required.