Naming of fallback john-* binaries

Hello,
there is some discrepancy between the naming conventions used for the john packages/releases. As we are starting discussions about stream-lining the "make install" it might be beneficial to discuss and take the decisions on what the naming should be.

We has some discussion about that with @solardiz over emails and concluded this will be probably also interesting topic to @claudioandre-br and possibly others.

Currently there exists more than 3 naming conventions for john binaries :
1) john-CPUFEATURE / john-omp-CPUFEATURE
- used mainly by the john core
- default john-sse2 is without OMP,
- the binary with OMP has -omp- in the name
- suggested in param.h
- john-omp mentioned in run/john.bash_completion, doc/FAQ:OpenMP-enabled, doc/README:choose
- use https://github.com/openwall/Owl/blob/main/packages/john/john.spec

2) john-CPUFEATURE / john-CPUFEATURE-non-omp
- used by jumbo where OMP is enabled by default john-CPUFEATURE (ex: john-sse2) binary
- binaries wihtout OMP have extension -non-omp
- params.h, doc/README-DISTROS mentions john-non-omp
- packaging/build.sh using john-CPUFEATURE-non-omp
- suggested on https://github.com/openwall/john/wiki/Fallback-binary-chains
- it is bit strange to see in name what feature is not enabled as there might be probably more features missing, like opencl

3) john-non-CPUFEATURE / john-non-omp-non-CPUFEATURE
- example: john-non-avx512f, john-non-avx512bw, john-non-mmx, john-non-omp-non-avx,
- mic.h, params.h, x86-64.h, x86-sse.h
- given probably just as example
- have not seen this really used in some packaging, as it is bit unpractical to list features missing rather than features present

4) john-OS-ARCH-CPUFEATURE - for example john-macosx-x86-64
- John core was using Makefile targets in form of OS-ARCH-CPUFEATURE
- for some (macos) targets in was moving files to run/ as
- src/Makefile.in , src/Makefile.legac

It would be nice to consolidate that.
What I am worried most is that john-CPUFEATURE (ex. john-sse2) can be with or without OMP, depending on where it came from, which might bring some unnecessary ambiguity.

Kali linux is dealing with this issue by adding -omp to the binaries built with OMP, but it's bringing some -omp redundancy in names:
/usr/lib/john/john-avx-non-omp
/usr/lib/john/john-avx-omp
/usr/lib/john/john-avx2-non-omp
/usr/lib/john/john-avx2-omp
/usr/lib/john/john-avx512bw-non-omp
/usr/lib/john/john-avx512bw-omp
/usr/lib/john/john-avx512f-non-omp
/usr/lib/john/john-avx512f-omp
/usr/lib/john/john-base-non-omp
/usr/lib/john/john-base-omp
/usr/lib/john/john-xop-non-omp
/usr/lib/john/john-xop-omp

Personally, I would rather see in name what is there and not what is missing, as we could be missing a lot of things/features.
CPU features are also saying what is there and not what is missing.
We are also not using the "john-non-avx512" binaries as suggested in the header files so I believe with same logic we should not be using "-non-omp". But if you decide to continue using "-non-omp".

Best regards
Michal Ambroz

This is an unresolved naming-policy discussion covering src/Makefile.in, src/Makefile.legac, params.h, mic.h, x86-64.h, x86-sse.h, packaging/build.sh, run/john.bash_completion, and related documentation. Start by comparing those references with the listed package and fallback conventions. Done means an agreed convention is documented and applied consistently across the affected build and packaging references.