sanity_checks: accept dash in packages' version strings

[rherilier]

Projects may use dashs ('-') in their version strings (for example, taocpp-json use "-beta.N" for years) but it prevents accepting such projecs in the wrapdb database.

As the string is splitted with rsplit(1), such version strings should not cause a problem.

[rherilier]

typo in commit message...

[eli-schwartz]

Projects may use dashs ('-') in their version strings (for example, taocpp-json use "-beta.N" for years) but it prevents accepting such projecs in the wrapdb database.

Many software packaging systems handle this by fully rejecting such version strings and mandating that adding those packages to the database should first involve mangling the version string to a consistent format, for example replacing dashes with underscores.

[bgilbert]

With this change, I believe the script would decide that the package version was beta.14, which doesn't seem to be what you'd want.

[rherilier]

with version equal to 1.0.0-beta.14-1 (which is the correct version scheme in wrapdb), rsplit(1) should make ver contains 1.0.0-beta.14 and rev 1, which is what is wanted by sanity_checks to work.

[rherilier]

@eli-schwartz

I'm not sure to understand...

The documentation of wrapDB does have any constraint for the entries' version string. The only one is for the wrap filename (the given regexp is [a-z0-9._]+) but this is neither respected in practice (73 packages use a dash in their wrap name) nor by sanity_checks.py (which does not do any test).

And if you look at the content of releases.json, all wrap versions match the scheme package-version-wrapdb-revision and the use of rsplit(1) in sanity_checks.py to get those 2 information reflect this implicit rule.

So, I don't see any reason for not supporting the dash in packages' version.

[bgilbert]

It's not true that there's no restriction on dashes in the version number. The restriction is explicitly enforced by the code you're modifying.

You're right that rsplit would do the right thing here. Dashes in versions can still cause problems, though, even if the WrapDB tooling were okay with it¹. If you have a tarball named taocpp-json-1.0.0-beta.14.tar.gz, how is a general-purpose tool supposed to parse out the package name and version number from the filename? Some package managers care about that.

¹ versions.py would also need an update, and possibly other tools as well?