Launchpad fails to upload packages with non-debian version strings
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
High
|
Unassigned |
Bug Description
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.
OOPS ids:
95d02552a477efb
c68ad170c61e280
Example versions:
9.0.0_1
1!161.3030-
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!
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!