We have implemented "hard" constraints that force selection of a version. These are useful for ensuring that a desired version of a package is used consistently within a single build-order file.
There may also be utility in "soft" constraints to allow us to have a common set of dependencies between variants. If we take as input a build-order file and use that as a source of suggested constraints, to be applied only if they are actually compatible with the requirements and ignored otherwise, then someone could run 2 bootstrap operations for variants back-to-back and end up using consistent versions of packages reliably. This would be different from the existing hard constraints in that we would warn but not report an error if the version in the build-order file was not compatible with the requirements being bootstrapped.
Another way to achieve this consistency could be to take multiple build-order files as input and look for common requirements and resolve them to a common value based on the inputs. That could end up being more complex, because we would have to ensure we correctly update all of the dependencies of anything where we changed a version. We may not have enough information in a build-order file to do that today.
Before anyone starts working on this one, let's talk about prioritization.
We have implemented "hard" constraints that force selection of a version. These are useful for ensuring that a desired version of a package is used consistently within a single build-order file.
There may also be utility in "soft" constraints to allow us to have a common set of dependencies between variants. If we take as input a build-order file and use that as a source of suggested constraints, to be applied only if they are actually compatible with the requirements and ignored otherwise, then someone could run 2 bootstrap operations for variants back-to-back and end up using consistent versions of packages reliably. This would be different from the existing hard constraints in that we would warn but not report an error if the version in the build-order file was not compatible with the requirements being bootstrapped.
Another way to achieve this consistency could be to take multiple build-order files as input and look for common requirements and resolve them to a common value based on the inputs. That could end up being more complex, because we would have to ensure we correctly update all of the dependencies of anything where we changed a version. We may not have enough information in a build-order file to do that today.
Before anyone starts working on this one, let's talk about prioritization.