search

spkenv / spk

A Package Manager for high velocity software environments, built on spfs.
https://spkenv.dev
Apache License 2.0
40 stars 6 forks source link

Distro compat range #1034

Closed jrray closed 3 months ago

jrray commented 5 months ago

At SPI we recently started building package for Rocky while on Rocky 9.3, and on Rocky the host options detect the version as "9.3", whereas on CentOS the version was detected as just "7". Now we are starting to build systems with Rocky 9.4, and since that generates a host option of "rocky": "9.4" the solver is unwilling to pick up any packages that were built on Rocky 9.3.

This PR explores one idea for solving this problem. It introduces the ability to set a compat value on a var option, as in:

build:
  options:
    - var: distro
    - var: rocky
      compat: "x.b"

Note these vars would normally be auto-generated for a recipe and in this PR it auto-generates the "rocky" var with the compat enabled based on a hard coded list of distro names.

The logic for handling this is when checking for compatibility, it first compares the values as raw strings like usual, so like before it would detect this inequality:

"9.3" != "9.4"

But now before returning incompatible for this case, if the option has a compat value, then the two sides are treated as version numbers and checked against the defined compat rule.

Here is an example of what the incompatibility message looks like in the situation where the versions are not considered compatible: image

This gets us part of the way to what we want. If we build a package on Rocky 9.3, we can use it on Rocky 9.4. But with the current semantics, if we build a package on Rocky 9.4, we can't use it on Rocky 9.3. To fully get the behavior we want (since rhel-based OSes promise up-and-down binary compatibility) then perhaps Compat needs to be extended to have a way to express, like a capital letter could indicate bidirectional compatibility: x.B.

We'd also need a way to configure the compat rules so it isn't hard coded into the source code.

Being able to use a compat value and this new behavior on any var option seems like it could be useful feature. It adds a way for package authors to describe extra dimensions of compatibility ranges. But I don't have any particular use cases in mind besides this distro one.

Edit: the hard-coded compat rules have been replaced by a new spk config section.

rydrman commented 3 months ago

From the meeting today: