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.

[ryandesign (Ryan Carsten Schmidt)]

Observe that archive names do not contain the epoch, therefore you must ensure that a port's version/revision combination is unique (different from any previously-published version/revision combination of that port) even if you have increased the epoch.

[RJVB (René Bertin)]

What archive names, the tar bundles in var/macports/software?

All I know is that port upgrade qca worked without a glitch on my end. From that I would deduce that the upgrade mechanism sees the increased epoch, and clearly decided to overwrite the old archives without requiring me to use --force.

But if someone wants to restore the revision numbers from before the reverted upgrade to 2.3.4 (or even increase them), I have nothing against that.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

Observe that archive names do not contain the epoch, therefore you must ensure that a port's version/revision combination is unique (different from any previously-published version/revision combination of that port) even if you have increased the epoch.

Ryan, we'll take a closer look at all of this, once the buildbots finish rebuilding the changes just committed via ​PR 13010 - qca-qt5: fix build on macOS 10.7-10.11

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

What archive names, the tar bundles in var/macports/software?

Yes.

All I know is that port upgrade qca worked without a glitch on my end. From that I would deduce that the upgrade mechanism sees the increased epoch, and clearly decided to overwrite the old archives without requiring me to use --force.

That's nice. But if a user still had e.g. the old qca @2.2.1_0 from 2019 installed, MacPorts would not have upgraded them to your new qca @2.2.1_0. If we still had the archives from that time on the server, the old archives would have been downloaded. There may be other failure modes associated with this problem.

But if someone wants to restore the revision numbers from before the reverted upgrade to 2.3.4 (or even increase them), I have nothing against that.

You are the maintainer of the port and are responsible for maintaining it correctly. You are the one who knows whether you've changed anything in the port that warrants a revision increase as compared to the port's previous iteration. You should set the revisions as needed, per my original report.

[RJVB (René Bertin)]

Replying to ryandesign:

That's nice. But if a user still had e.g. the old qca @2.2.1_0 from 2019 installed, MacPorts would not have upgraded them to your new qca @2.2.1_0.

Full disclosure: that's what I had (still have, probably, in deactivated state). I don't often bother to reinstall my own ports if it's just for a revbump because of some dependency that I also didn't bother to upgrade, esp. not if I have a custom copy in my own ports tree.

To be honest, I'd like to see proof that this is an actual issue, and not yet another clash of principles. As far as I've seen (= often enough), increasing the epoch simply causes a forced upgrade allowing for a complete change of the versioning scheme (i.e. to one that cannot be compared to the previous version sensibly). And that should still be the case unless this was changed in a newer "base" version that I haven't yet updated to.

You are the maintainer of the port and are responsible for maintaining it correctly. You are the one who knows whether you've changed anything in the port that warrants a revision increase as compared to the port's previous iteration. You should set the revisions as needed, per my original report.

Well then we're all set - nothing warrants a revision increase, and in my opinion the downgrade warranted a reset of the revisions (again, in my opinion, because major version change and a change of epoch).

It's accepted practice that others revbump ports they don't maintain when there's a reason; this seems to be the case. You know I don't have commit permissions to do this myself, and I'm not going to do it through a dedicated PR.

FWIW: if memory still serves me well, I certainly didn't ask to be the sole maintainer of this port, there must at least have been a co-maintainer (I think I was asked to maintain the Qt5 subports). I also don't know why the port doesn't have openmaintainer status; it should.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

That's nice. But if a user still had e.g. the old qca @2.2.1_0 from 2019 installed, MacPorts would not have upgraded them to your new qca @2.2.1_0. If we still had the archives from that time on the server, the old archives would have been downloaded. There may be other failure modes associated with this problem.

Ah, that was the missing piece for me: We don't want to revert to precisely the same version/revision. At least not unless both the build archive - and folks' local installations - are guaranteed to represent precisely the same results as we'd get today.

So in such a case, it would be safer to bump the revision to a value one greater than anything used previously.

Rene, does that make sense?

[RJVB (René Bertin)]

Yeah, I guess that what Ryan wants to see is exactly that. As I said, I have nothing against it, but I'd like to see proof that it's necessary. Or proof I'm wrong, if you prefer.

Because if I'm not wrong, doing a revbump will force an unnecessary rebuild/upgrade on the bots and everyone who has the Qt4 subports installed.

[mascguy (Christopher Nielsen)]

Replying to RJVB:

Yeah, I guess that what Ryan wants to see is exactly that. As I said, I have nothing against it, but I'd like to see proof that it's necessary. Or proof I'm wrong, if you prefer.

Because if I'm not wrong, doing a revbump will force an unnecessary rebuild/upgrade on the bots and everyone who has the Qt4 subports installed.

True, and we don't want to unnecessarily rev-bump on a whim. But in a case like this, where we want to be absolutely sure that both the binary archive - and folks' local installations - are up-to-date, it might be worthwhile.

[RJVB (René Bertin)]

So I've been tinkering with this issue, first revbumping my local copy of port:qca-qt5-ossl so that the archive directory had

> ll -htr /opt/local/var/macports/software/qca-qt5-ossl
total 1.7M
103736 517K -rw-r--r--    1 root   root 463K Sep 12  2019 qca-qt5-ossl-2.2.1_1+LTO+langselect+qt5kde.linux_3.x86_64.tbz2
 47758 517K -rw-r--r--    1 root   root 471K Nov 13 15:33 qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2
     4 145K drwxrwxr-x 1195 bertin adm  1.2K Nov 13 15:33 ../
 47767 517K -rw-r--r--    1 root   root 471K Nov 21 12:36 qca-qt5-ossl-2.3.4_1+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2
   436  25K drwxrwxr-x    2 root   adm     5 Nov 21 12:36 ./

(this is on my "LinuxPorts" system, which runs exactly the same MacPorts version as I have on Mac; there's no ground to believe it would handle epoch/revision issues any differently. Nor that my custom variants would have any influence here.)

After installing the revision 1 version of the port, I edited the Portfile (revision -> epoch), and ran the following command using the exact same destroot directory which I had kept. So we have the added situation that the port's files are all strictly identical, down to the hash and dates.

Contrary to what I expected, port upgrade qca-qt5-ossl did nothing. port install qca-qt5-ossl did, but it just activated the "revision 0" version.

Next, I realised that the Qt4 ports had been updated to 2.3.4, so, still using the same destroot, I removed the epoch statement from the Portfile and bumped the version to 2.3.5 (with revision 0; this installed v2.3.4 pretending to be v2.3.5). Then, I reverted the version change, and added epoch 1 and saw this:

> sudo port -nok upgrade qca-qt5-ossl
--->  Computing dependencies for qca-qt5-ossl
--->  Uninstalling qca-qt5-ossl @2.3.4_0+LTO+cpucompat+langselect+qt5kde
--->  Cleaning qca-qt5-ossl
--->  Computing dependencies for qca-qt5-ossl
--->  Installing qca-qt5-ossl @2.3.4_0+LTO+cpucompat+langselect+qt5kde
--->  Deactivating qca-qt5-ossl @2.3.5_0+LTO+cpucompat+langselect+qt5kde
--->  Cleaning qca-qt5-ossl
--->  Activating qca-qt5-ossl @2.3.4_0+LTO+cpucompat+langselect+qt5kde

This gave me the following archive directory:

> ll -htr /opt/local/var/macports/software/qca-qt5-ossl
total 2.2M
103736 517K -rw-r--r--    1 root   root 463K Sep 12  2019 qca-qt5-ossl-2.2.1_1+LTO+langselect+qt5kde.linux_3.x86_64.tbz2
     4 145K drwxrwxr-x 1195 bertin adm  1.2K Nov 13 15:33 ../
 47767 517K -rw-r--r--    1 root   root 471K Nov 21 12:36 qca-qt5-ossl-2.3.4_1+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2
 47927 517K -rw-r--r--    1 root   root 471K Nov 21 12:51 qca-qt5-ossl-2.3.5_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2
 47928 517K -rw-r--r--    1 root   root 471K Nov 21 12:51 qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2
   436  25K drwxrwxr-x    2 root   adm     6 Nov 21 12:51 ./

The logfile for the install (short enough to paste, I think):

version:1
:debug:sysinfo Linux 4.14.23-ck1-mainline-core2-rjvb (linux/4.14.23-ck1-mainline-core2-rjvb) arch x86_64
:debug:sysinfo MacPorts 2.6.2.86
:msg:clean --->  Computing dependencies for qca-qt5-ossl:info:clean .:debug:clean qca-qt5-ossl has no conflicts
:debug:clean Searching for dependency: xz
:debug:clean Found Dependency: receipt exists for xz
:debug:clean Searching for dependency: cmake
:debug:clean Found Dependency: receipt exists for cmake
:debug:clean Searching for dependency: openssl3-dev
:debug:clean Found Dependency: receipt exists for openssl3-dev
:debug:clean Searching for dependency: pkgconfig
:debug:clean Found Dependency: receipt exists for pkgconfig
:debug:clean Searching for dependency: qca-qt5
:debug:clean Found Dependency: receipt exists for qca-qt5
:debug:clean Searching for dependency: openssl3
:debug:clean Found Dependency: receipt exists for openssl3
:debug:main Executing org.macports.main (qca-qt5-ossl)
:debug:main dropping privileges: euid changed to 505, egid changed to 505.
:debug:archivefetch archivefetch phase started at Sun Nov 21 12:51:39 CET 2021
:debug:archivefetch Executing org.macports.archivefetch (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.fetch (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.checksum (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.extract (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.patch (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.configure (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.build (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:archivefetch Skipping completed org.macports.destroot (qca-qt5-ossl)
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:install install phase started at Sun Nov 21 12:51:39 CET 2021
:notice:install --->  Installing qca-qt5-ossl @2.3.4_0+LTO+cpucompat+langselect+qt5kde
:debug:install elevating privileges for install: euid changed to 0, egid changed to 0.
:debug:install Executing org.macports.install (qca-qt5-ossl)
:debug:install Using /bin/tar
:debug:install Using /usr/bin/pbzip2 -c9 
:debug:install checksum file: /opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot/opt/local/share/qt5/plugins/crypto/libqca-ossl.so
:debug:install Creating qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2
:debug:install Environment: 
:debug:install CPATH='/opt/local/include'
:debug:install DEVELOPER_DIR=''
:debug:install LIBRARY_PATH='/opt/local/lib'
:debug:install Executing:  cd "/opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot" && /bin/tar -cvf - . | /usr/bin/pbzip2 -c9 > /opt/local/var/lnxports/software/qca-qt5-ossl/qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2 
:debug:install system:  cd "/opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot" && /bin/tar -cvf - . | /usr/bin/pbzip2 -c9 > /opt/local/var/lnxports/software/qca-qt5-ossl/qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2 
:info:install ./
:info:install ./+PORTFILE
:info:install ./+CONTENTS
:info:install ./+COMMENT
:info:install ./+STATE
:info:install ./+DESC
:info:install ./opt/
:info:install ./opt/local/
:info:install ./opt/local/share/
:info:install ./opt/local/share/qt5/
:info:install ./opt/local/share/qt5/plugins/
:info:install ./opt/local/share/qt5/plugins/crypto/
:info:install ./opt/local/share/qt5/plugins/crypto/libqca-ossl.so
:debug:install Archive qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2 packaged
:debug:install removing file: /opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot/+PORTFILE
:debug:install removing file: /opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot/+CONTENTS
:debug:install removing file: /opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot/+COMMENT
:debug:install removing file: /opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot/+STATE
:debug:install removing file: /opt/local/var/lnxports/build/_opt_local_site-ports_devel_qca/qca-qt5-ossl/work/destroot/+DESC
:debug:activate activate phase started at Sun Nov 21 12:51:39 CET 2021
:debug:activate Executing org.macports.activate (qca-qt5-ossl)
:debug:activate Using normalized porturl file:///opt/local/var/lnxports/registry/portfiles/qca-qt5-ossl-2.3.5_0/fb15f4575dc5aefa721606a3f28e63c1fc0419077f243fad03367d597e1eb240-7754
:debug:activate Changing to port directory: /opt/local/var/lnxports/registry/portfiles/qca-qt5-ossl-2.3.5_0/fb15f4575dc5aefa721606a3f28e63c1fc0419077f243fad03367d597e1eb240-7754
:debug:activate OS linux/4.14.23-ck1-mainline-core2-rjvb arch x86_64
:debug:activate Already installed Qt5 version: qt5 (qt5-qtbase)
:debug:activate Qt5 is provided by port:qt5-kde; transferring to PortGroup qt5-kde 1.0
:debug:activate Qt5 is provided by port:qt5-kde
:debug:activate +qt5kde is set for port:qca-qt5-ossl
:debug:activate Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/lnxports/registry/portgroups/4af6c3c88f20ed3161ad8a1d250c796fc7f8d4d7117857d278897f0bd15fc0c7-5084/compiler_blacklist_versions-1.0.tcl
:debug:activate available_apple_compilers=
:debug:activate Picking compiler from fallbacks cc macports-clang-3.4 macports-clang-3.3 macports-gcc-7 macports-gcc-6 macports-gcc-5
:debug:activate Adding depspec "path:libexec/qt5/lib/libQt5Core.so:qt5-kde" (/opt/local/var/lnxports/registry/portgroups/9ed7b10c09cdad4b8d6aa7f8b92b76b82039020a632112df0b624e39e84ae716-44676/qt5-kde-1.0.tcl)
:debug:activate LTO: setting LTO compiler and linker option(s) "-ftracer -flto -fuse-linker-plugin -ffat-lto-objects"
:debug:activate Re-registering default for LTO.cpuflags
:debug:activate Sourcing PortGroup LTO 1.0 from /opt/local/var/lnxports/registry/portgroups/537c7901e8559db9bd5225ea68ebcbc050a1920da967111db1528ea6ca465d96-11087/LTO-1.0.tcl
:debug:activate Sourcing PortGroup locale_select 1.0 from /opt/local/var/lnxports/registry/portgroups/125f26dac2be21443dadd842b4f8b26e3a13318eaba57029f445268bb1cd1f06-7514/locale_select-1.0.tcl
:debug:activate Sourcing PortGroup qt5-kde 1.0 from /opt/local/var/lnxports/registry/portgroups/9ed7b10c09cdad4b8d6aa7f8b92b76b82039020a632112df0b624e39e84ae716-44676/qt5-kde-1.0.tcl
:debug:activate Sourcing PortGroup qt5-stock 1.0 from /opt/local/var/lnxports/registry/portgroups/5a202dadf43e9ec7eb5769ca74328e8ad013cb67d3b49bb3c0c10a6a5a81bcd1-37198/qt5-stock-1.0.tcl
:debug:activate Sourcing PortGroup qt5 1.0 from /opt/local/var/lnxports/registry/portgroups/75f86574c5d39bd484dce9f60b0f739b2f557170805d4d640f049fd02c062ae6-6661/qt5-1.0.tcl
:debug:activate Re-registering default for destroot.target
:debug:activate Re-registering default for configure.dir
:debug:activate Re-registering default for build.dir
:debug:activate Re-registering default for configure.pre_args
:debug:activate Sourcing PortGroup cmake 1.1 from /opt/local/var/lnxports/registry/portgroups/75a69282dc6940f5841cac13cfbb2d0c659192188816fe9b4a0e5e11884fe334-32380/cmake-1.1.tcl
:debug:activate available_apple_compilers=
:debug:activate Picking compiler from fallbacks cc macports-clang-3.4 macports-clang-3.3 macports-gcc-7 macports-gcc-6 macports-gcc-5
:debug:activate Sourcing PortGroup openssl 1.0 from /opt/local/var/lnxports/registry/portgroups/7a2b9bad7723e8b142f8461a85152bdbe6e8a0df1361e08345b23510e86ad08f-7898/openssl-1.0.tcl
:debug:activate universal_variant is false, so not adding the default universal variant
:debug:activate Executing variant qt5kde provides qt5kde
:debug:activate Executing variant LTO provides LTO
:debug:activate Executing variant cpucompat provides cpucompat
:debug:activate Executing variant langselect provides langselect
:debug:activate Running callback portconfigure::add_automatic_compiler_dependencies
:debug:activate Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:activate Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:activate Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:activate Running callback portstartupitem::add_notes
:debug:activate Finished running callback portstartupitem::add_notes
:debug:activate Running callback openssl::set_openssl_dependency
:debug:activate Finished running callback openssl::set_openssl_dependency
:debug:activate Running callback openssl::check_for_cmake
:debug:activate Appending cmake to openssl configuration types
:debug:activate Configure Types 'pkgconfig build_flags cmake'
:debug:activate  -> Setting openssl pkgconfig configuration
:debug:activate  -> Setting openssl build flags configuration
:debug:activate  -> Setting openssl cmake configuration
:debug:activate Finished running callback openssl::check_for_cmake
:debug:activate Running callback openssl::configure_build
:debug:activate Finished running callback openssl::configure_build
:debug:activate Starting logging for qca-qt5-ossl
:debug:main Executing org.macports.main (qca-qt5-ossl)
:debug:clean clean phase started at Sun Nov 21 12:51:40 CET 2021
:notice:clean --->  Cleaning qca-qt5-ossl
:debug:clean Executing org.macports.clean (qca-qt5-ossl)
:info:clean --->  Removing work directory for qca-qt5-ossl
:debug:clean No work directory found to remove at /opt/local/var/lnxports/build/_opt_local_var_lnxports_registry_portfiles_qca-qt5-ossl-2.3.5_0_fb15f4575dc5aefa721606a3f28e63c1fc0419077f243fad03367d597e1eb240-7754/qca-qt5-ossl
:debug:clean Removing directory: /opt/local/var/lnxports/logs/_opt_local_var_lnxports_registry_portfiles_qca-qt5-ossl-2.3.5_0_fb15f4575dc5aefa721606a3f28e63c1fc0419077f243fad03367d597e1eb240-7754/qca-qt5-ossl
:msg:clean --->  Activating qca-qt5-ossl @2.3.4_0+LTO+cpucompat+langselect+qt5kde
:debug:clean Using /bin/tar
:debug:clean Using /usr/bin/pbzip2
:debug:clean system: /usr/bin/pbzip2 -d -c '/opt/local/var/lnxports/software/qca-qt5-ossl/qca-qt5-ossl-2.3.4_0+LTO+cpucompat+langselect+qt5kde.linux_3.x86_64.tbz2' | ( /bin/tar -xvpf - )
:info:clean ./
:info:clean ./+PORTFILE
:info:clean ./+CONTENTS
:info:clean ./+COMMENT
:info:clean ./+STATE
:info:clean ./+DESC
:info:clean ./opt/
:info:clean ./opt/local/
:info:clean ./opt/local/share/
:info:clean ./opt/local/share/qt5/
:info:clean ./opt/local/share/qt5/plugins/
:info:clean ./opt/local/share/qt5/plugins/crypto/
:info:clean ./opt/local/share/qt5/plugins/crypto/libqca-ossl.so
:debug:clean activating directory: /
:debug:clean activating directory: /opt
:debug:clean activating directory: /opt/local
:debug:clean activating directory: /opt/local/share
:debug:clean activating directory: /opt/local/share/qt5
:debug:clean activating directory: /opt/local/share/qt5/plugins
:debug:clean activating directory: /opt/local/share/qt5/plugins/crypto
:debug:clean activating file: /opt/local/share/qt5/plugins/crypto/libqca-ossl.so
:debug:clean Executing proc-post-org.macports.activate-activate-0
:debug:clean Qt help collection: tDir "/opt/local/share/doc/qt5"=1631780765 , tchDir "/opt/local/share/doc/qch"=1625778090 , File "/opt/local/share/doc/qt5/MP-qthelp-collection.qhc" 1631780765
:debug:clean Executing portactivate::activate_finish
:debug:main Executing org.macports.main (qca-qt5-ossl)
:debug:load load phase started at Sun Nov 21 12:51:40 CET 2021
:debug:load Executing org.macports.load (qca-qt5-ossl)

So my belief of the effect epoch can have was not unfounded, and appears to be different in how it handles downgrades in version and downgrades in revision. I find that surprising to say the least. Of course there's one difference in this final scenario compared to what users of the Qt4 subports will encounter: I actually got to install the (fake) new version. I also didn't run portindex, so I repeated the procedure. Rev-bumped v2.3.4, ran portindex, did an upgrade --force (necessary here, just to refresh the 2.3.4_1 install). Then I reverted the revision, re-increased the version to the fake 2.3.5, ran portinex and did not upgrade the port. Reverted the version upgrade and added epoch 1 followed by yet another portindex. This time, no upgrade as predicted by Ryan.

Looks like I'm going to have to see if the history of the terminal I used for updating the Qt4 subports on my Mac still shows exactly what I did! (Or maybe repeat my tests to see if maybe "base" does behave differently on Mac...)

[RJVB (René Bertin)]

Replying to RJVB:

Of course there's one difference in this final scenario compared to what users of the Qt4 subports will encounter: I actually got to install the (fake) new version.

AAAAHHHHHH

That's where I think we all went wrong.

The wrongly upgraded Qt4 subports (qca and qca-*) actually do build and install!! But, since they actually build the same things as the Qt5 subports (qca-qt5 and qca-qt5-*), they fail in the activation stage.

So my scenario wasn't wrong, the only thing I could have done to make it more representative was to activate the real (= non-faked, 2.3.4_1) version of the port before trying to "upgrade" to 2.3.4_0+epoch1. But in practice that shouldn't have mattered: MacPorts will upgrade regardless of which version is active AFAIK.

Still, it would be nice if there was less ambiguity in how epoch interacts with downgrades in version and downgrades in revision! Even if this difference is documented somewhere I don't see why it would exist: to me the revision scheme is just an additional element to the "native" versioning, a "downstream patchlevel" if you want. If epoch is intended to work as a reset for the versioning scheme it should affect both those levels, upstream and downstream.

[RJVB (René Bertin)]

I checked the history on my Mac, and can no longer say with certainty what happened there; it turns out the main port was NOT updated (`port:qca was at 2.2.1_1) but the subports were.

HOWEVER, I simulated the botched upgrade to 2.3.4 by increasing the version and removing the epoch after doing a port destroot and copying a file from one of the qca-qt5 subports. That caused the upgrade to fail like it failed for everyone using the stock port:qca : at the activation stage after the actual installation of the "new" version. Then, I reverted the version back to 2.2.1 and restored the epoch. The port upgraded perfectly to 2.2.1_0, as predicted by my previous post.

I think thus that there is indeed no reason to restore the revisions as they were before any upgrade to 2.3.4 .

If somehow there are a few users for whom the old qca/Qt4 2.2.1_0 port(s) get reactivated instead of a fresh install, they should get rev-upgrade errors or else runtime issues in the dependents. Normally I'd prefer to avoid exposing even a few users to that, but in this case I prefer not exposing everyone else to a probably unnecessary upgrade (no matter how trivial that may seem).