colm @0.14.7_0 was published twice

[barracuda156]

No idea atm what has broken it:

In file included from inputdata.h:26,
                 from main.cc:23:
nragel.h:25: error: redefinition of ‘struct HostLang’
/opt/local/include/libfsm/common.h:226: error: previous definition of ‘struct HostLang’
nragel.h:47: error: redefinition of ‘class output_filter’
/opt/local/include/libfsm/common.h:397: error: previous definition of ‘class output_filter’
nragel.h:73: error: redefinition of ‘class cfilebuf’
/opt/local/include/libfsm/common.h:433: error: previous definition of ‘class cfilebuf’
nragel.h:100: error: redefinition of ‘class costream’
/opt/local/include/libfsm/common.h:460: error: previous definition of ‘class costream’
In file included from inputdata.h:26,
                 from reducer.h:41,
                 from rlreduce.cc:20:
nragel.h:25: error: redefinition of ‘struct HostLang’
/opt/local/include/libfsm/common.h:226: error: previous definition of ‘struct HostLang’
nragel.h:47: error: redefinition of ‘class output_filter’
/opt/local/include/libfsm/common.h:397: error: previous definition of ‘class output_filter’
nragel.h:73: error: redefinition of ‘class cfilebuf’
/opt/local/include/libfsm/common.h:433: error: previous definition of ‘class cfilebuf’
nragel.h:100: error: redefinition of ‘class costream’
/opt/local/include/libfsm/common.h:460: error: previous definition of ‘class costream’
In file included from main.cc:23:
inputdata.h: In constructor ‘InputData::InputData(const HostLang*, colm_sections*, colm_sections*)’:
inputdata.h:214: error: no matching function for call to ‘FsmGbl::FsmGbl()’
/opt/local/include/libfsm/fsmgraph.h:1019: note: candidates are: FsmGbl::FsmGbl(const HostLang*)
/opt/local/include/libfsm/fsmgraph.h:1018: note:                 FsmGbl::FsmGbl(const FsmGbl&)
/opt/local/include/libfsm/common.h: At global scope:
/opt/local/include/libfsm/common.h:245: error: previous declaration of ‘const HostLang hostLangC’ with ‘C++’ linkage
main.cc:26: error: conflicts with new declaration with ‘C’ linkage
In file included from reducer.h:41,
                 from rlreduce.cc:20:
inputdata.h: In constructor ‘InputData::InputData(const HostLang*, colm_sections*, colm_sections*)’:
inputdata.h:214: error: no matching function for call to ‘FsmGbl::FsmGbl()’
/opt/local/include/libfsm/fsmgraph.h:1019: note: candidates are: FsmGbl::FsmGbl(const HostLang*)
/opt/local/include/libfsm/fsmgraph.h:1018: note:                 FsmGbl::FsmGbl(const FsmGbl&)
make[3]: *** [ragel-main.o] Error 1

Need to check a native build – if this is Rosetta-only failure or not.

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

nragel.h:25: error: redefinition of ‘struct HostLang’
/opt/local/include/libfsm/common.h:226: error: previous definition of ‘struct HostLang’

The colm port was updated from 0.13.0.7_0 to 0.14.7_0 in October 2021. This version of the port ​provided a file /opt/local/include/libfsm/common.h that defined struct HostLang on line 226. This must be the version of the port that you have installed on your machine.

That update was reverted in November 2021 because it was incompatible with ragel and the port was downgraded back to 0.13.0.7_0. The epoch was increased to facilitate the downgrade. If you had run sudo port selfupdate and sudo port upgrade outdated at that time MacPorts should have downgraded your colm to 0.13.0.7_0, leaving the bad 0.14.7_0 installed but inactive (unless you used the -u flag when upgrading).

You submitted a new update to the port in October 2022 which set its version and revision back to 0.14.7_0 (typo'd as "0.4.17" in the commit message) but which actually updated the port to a later commit of the code. This version of colm ​provides a file /opt/local/include/libfsm/common.h that does not define nor mention struct HostLang and is therefore compatible with ragel. However, if you still have the October 2021 0.14.7_0 version of the port installed (and you skipped the November 2021 downgrade to 0.13.0.7_0), MacPorts will not inform you of the new 0.14.7_0 because as far as MacPorts can tell they are the same since the version and revision are the same. The epoch is only consulted if the versions differ. It's even possible that, if you accepted the November 2021 0.13.0.7_0 downgrade but did not uninstall the October 2021 0.14.7_0 version, after October 2022 MacPorts would have simply re-activated the October 2021 0.14.7_0 that you still had installed rather than installing the new one.

The moral of the story is that a version and revision combination of a port must be considered unique. One must not publish the same version and revision combination more than once with different contents, as happened here. The solution is to increase the version and revision of the port to a combination that was never published before, such as 0.14.7_1, so that we can be assured that there are no remaining users who are inadvertently using the October 2021 0.14.7_0 build.

[ryandesign (Ryan Carsten Schmidt)]

In 289277de604c16d8eb117876fd98c8b2bed67ff4/macports-ports (master):

colm: Increase revision

Closes: #66604

colm @0.14.7_0 was published twice with different contents: once in
October 2021, and then in October 2022. Increase revision to ensure
there are no users inadvertently still using the October 2021 0.14.7_0
build.

[barracuda156]

Replying to ryandesign:

In 289277de604c16d8eb117876fd98c8b2bed67ff4/macports-ports (master):

colm: Increase revision

Closes: #66604

colm @0.14.7_0 was published twice with different contents: once in
October 2021, and then in October 2022. Increase revision to ensure
there are no users inadvertently still using the October 2021 0.14.7_0
build.

Thank you for fixing!