Release 6.0.0-crc64: enforce the LDB crc64 release line

[mscasso-scanoss]

Opens the CRC64 release line of the engine (6.x, branch crc64), mirroring the scanoss/ldb 5.0.0-crc64 release (scanoss/ldb#59).

Release line	Branch	Engine versions	Tag format	Requires LDB
Traditional	main	5.x	v5.5.1	4.x (main branch of scanoss/ldb)
CRC64-compatible	crc64	6.x and later	v6.0.0-crc64	5.x-crc64 (crc64 branch of scanoss/ldb)

Both lines are tagged in the same repository, so releases of this line carry a mandatory -crc64 suffix. It is also carried by SCANOSS_VERSION, so scanoss -v identifies the line a binary comes from.

LDB version validation

The engine links libldb dynamically, so the LDB present at build time is not necessarily the one loaded at run time. Both are now validated, and neither check can drift from the other: the requirement is declared once, in inc/ldb_compat.h, and read by both.

Build time — scripts/check_ldb_version.sh, run from the Makefile before any object is compiled

The previous check was ldb -v | head -c 3 compared with bc, which:

• truncated to 3 characters, so 5.0.0-crc64 became 5.0, and a two-digit major (10.0.0) became 10. and made bc fail with a syntax error;
• compared as a decimal rather than a semantic version, ranking 4.10 below 4.2;
• never inspected the suffix, so an MD5-only LDB passed;
• queried the binary on PATH, which need not be the build the linker resolves;
• depended on bc.

It now compares major/minor/patch numerically with shell arithmetic, requires the crc64 suffix, and reports "too old" and "wrong release line" as distinct, actionable failures.

It validates two sources and fails on either:

1. the ldb.h the compiler resolves — located and expanded by the preprocessor, so it honours CPPFLAGS rather than assuming /usr/include;
2. the libldb.so the linker resolves — probed by building and running a program against -lldb.

The header alone is not sufficient. On the development machine this was written on, a stale /usr/local/lib/libldb.so (4.2.2-beta) shadows the correct /usr/lib/libldb.so (5.0.0-crc64) because /usr/local/lib sorts first in ld.so.conf. A header-only check passes and the resulting binary then fails at run time on the very machine that built it. ldb -v is kept as a non-fatal hint only.

Run time — src/ldb_compat.c, called from initialize_ldb_tables()

The previous check used strcmp against "4.1.0", which is lexicographic: "5.10.0" sorts below "5.9.0", so the engine would refuse to start against a newer LDB. That 5.0.0-crc64 passed at all was an accident of string length. The version is now parsed into major/minor/patch plus suffix and held to the same rule as the build.

Fixes found while verifying the documentation against the code

• --force-snippet was declared required_argument in long_options, but case 256 never reads optarg and the help text shows no argument. So scanoss --force-snippet TARGET silently consumed TARGET as the option's argument. Corrected to no_argument.
• README documented --min-match-hits and --min-match-lines, which do not exist — the parser rejects them with "Unsupported option". The real names are --min-snippet-hits and --min-snippet-lines.
• README also described --force-snippet as "same as -b", omitted --max-file-content-size, -P/--purl, -C/--url-hash, -p/--project and -S/--snippet-scan, and pointed the install snippet at an archive of a nonexistent master branch.

Documentation and packaging

• SCANOSS_VERSION 5.5.2-beta → 6.0.0-crc64.
• README.md and docs/source/index.rst require LDB >= 5.0.0-crc64 and link the crc64 branch of the LDB README instead of master. Both document the release lines and note that the constraint comes from the on-disk table layout and the library API, not the hash mode, so it applies in MD5 too.
• CONTRIBUTING.md documents the branch and tag scheme, and that the LDB minimum lives in a single header.
• package.sh: RPM forbids - in the Version field, so the suffix is translated to _ for the spec (6.0.0-crc64 → 6.0.0_crc64). The deb keeps the hyphen.

CI

Both workflows cloned LDB from master — the 4.x MD5-only line, which the new check now rejects. This was a latent hard failure. They build from the crc64 branch instead. release.yml selected "the newest tag", which may belong to either line, and now picks the latest v*-crc64 tag specifically. build.yml also triggers on pull requests targeting crc64.

The actions/checkout@v3 and ::set-output deprecations are left untouched on purpose: they are warnings, and fixing them on this branch alone would introduce drift from main. They should be fixed on both branches together, in a separate change.

Verification

Built against a real LDB 5.0.0-crc64. 12/12 cases pass, using synthetic ldb.h files and actually rebuilt libldb.so variants:

LDB version	Build check	Run-time check
5.0.0-crc64	pass	pass
5.10.0-crc64	pass	pass — the old strcmp rejected this
10.0.0-crc64	pass	— the old head -c 3 + bc syntax-errored
4.10.0	reject, "too old"	— the old bc said 4.10 < 4.2
5.1.0 (no suffix)	reject, "MD5-only line"	reject, "MD5-only line"
4.2.2-beta	reject, "too old"	reject, "too old"

make aborts with 0 objects built. Clean rebuild produces no new warnings. scanoss -v, -h and the JSON server.version field all report 6.0.0-crc64, and real scans run correctly. RPM/deb version translation verified.

Not verified: the engine has no test suite (no run_test.sh, no test/), so unlike ldb there was nothing to run — functional checking was limited to real scans and scanoss -t. rpmbuild was not available, so the spec version translation was verified by replaying the package.sh logic rather than building a package.

No tag has been created; that is a separate, explicit decision.

🤖 Generated with Claude Code