Launchpad fails to upload packages with non-debian version strings

[Dan Ryan]

When building + releasing packages to artifactory in non-debian format -- specifically in this case, these are conda packages, launchpad fails to release the packages and emails me an upload error with an OOPS code indicating that the versions in question violate the database check constraint:

storm.database.CheckViolation: new row for relation "sourcepackagerelease" violates check constraint "valid_version"

OOPS ids:

95d02552a477efb006aa3e6a2ead5c04
c68ad170c61e280f0e1ffb80b93ede7a

Example versions:

9.0.0_1
1!161.3030-h7f98852_1

We can't really change the package versions in the actual packaging metadata, so this is going to prevent us from uploading these packages (and any others that hit this issue). Thanks for looking into this, I appreciate your help!

[Colin Watson (cjwatson)]

This is fundamentally because `{Source,Binary}PackageRelease.version` are built specifically as Debian-format version columns, with ordering rules that are consistent with Debian policy. We've crowbarred other package types into that and mostly got away with it so far, but we're hitting the limits of that early pragmatic approach now.

I think probably the least impractical option is to add version_string columns to the xPR tables, do something like `Coalesce(Cast(version, "text"), version_string)` anywhere that we currently do `Cast(version, "text")`, and change all the methods that currently order result sets by version to refuse to do so unless they're working with Debian-format packages. We'd then start setting `version_string` rather than `version` for non-Debian-format uploads, maybe with some very weak sanitization (e.g. no whitespace). This is all going to have to be done with a great deal of care though!