Drop the distro mutex's run_constraints

.claude/skills/robostack-versions/SKILL.md

@@ -25,8 +25,10 @@ change, or on request) open PRs that already contain the bumps below. Do it by h
     `distros/<d>/conda_build_config.yaml`.
 - **The mutex** (`mutex_package` in `distros/<d>/vinca.yaml`): `ros2-distro-mutex`
   with `upper_bound: x.x`. Packages built with mutex 0.11 can't be installed with
-  0.10 builds. Its `run_constraints` pin the ABI-relevant libraries for users'
-  environments and must agree with the rendered pins.
+  0.10 builds. It has no `run_constraints` (`rs check` enforces it): library versions
+  come from the packages' own dependencies. When an environment resolves to a broken
+  combination, fix the metadata of the package that is wrong (a patch,
+  `pkg_additional_info.yaml`, or a conda-forge repodata patch), never the mutex.
 
 ## Update the snapshot
 
@@ -53,12 +55,10 @@ pixi run rs <d> create-snapshot
 pixi run rs <d> update-pinning      # = bot command: latest pinning + rebuild plan for <d>
 pixi run rs update-pinning          # the same for every distribution
 pixi run rs <d> render-pinning      # after editing shared/pinning or distro.yaml
-pixi run rs <d> check-deps          # solve all non-ROS deps + mutex constraints, nothing built
+pixi run rs <d> check-deps          # solve all non-ROS deps together, nothing built
 ```
 
 `check-deps` reports:
-- `PIN MISMATCH`: a mutex `run_constraints` entry contradicts the rendered pin. Fix
-  `vinca.yaml` or the pinning; never `conda_build_config.yaml`.
 - Per conflicting package: the recipes that need it, the clashing pin, the solver
   explanation and the conda-forge migration status. "no migration" means the feedstock
   only needs a rebuild upstream.
@@ -78,9 +78,8 @@ host requirements, plus everything that depends on them (host or run, transitive
 are rebuilt; the rest keep their published builds.
 
 - **Partial rebuild** (the usual case): those packages get `build_number` = highest
-  released build + 1 in `distros/<d>/pkg_additional_info.yaml`, and when the mutex
-  `run_constraints` changed, the mutex gets a new build at the same version
-  (`mutex_package.build_number`), so all other published packages stay installable.
+  released build + 1 in `distros/<d>/pkg_additional_info.yaml`. The mutex stays as
+  it is, so all other published packages stay installable.
 - **Full rebuild** (more than half of the packages affected): the bump below.
 
 The PR lists the packages and why, the migrations used / waiting for our dependencies'
@@ -102,11 +101,9 @@ rebuilt:
 2. Mutex minor version + 1, e.g. `0.10.0` -> `0.11.0`. Nothing else hard-codes the
    mutex version.
 3. Remove all per-package `build_number` entries in `distros/<d>/pkg_additional_info.yaml`.
-4. Update mutex `run_constraints` to the new pins, then run `check-deps`.
-5. `pixi run rs check`.
+4. `pixi run rs <d> check-deps`, then `pixi run rs check`.
 
-The bot does 1–4. It only moves constraints of the form `<pkg> <version>.*`; ranges
-and other constraints are left for you to check.
+The bot does 1–3.
 
 In the PR, CI uses its cache unless told otherwise. A full rebuild PR sets
 `full_rebuild: true` in `distros/<d>/ci.yaml` (reset after merging).
@@ -123,15 +120,12 @@ In the PR, CI uses its cache unless told otherwise. A full rebuild PR sets
 ```bash
 pixi run rs <d> find-stale                                     # = bot find-stale-packages
 pixi run rs <d> check-deps --stale                             # local artifacts
-pixi run rs <d> check-deps --stale --mutex-only                # only mutex violations
 pixi run rs <d> check-deps --stale --repodata https://conda.anaconda.org/<channel>
 pixi run rs <d> check-deps --stale --delete                    # delete stale local artifacts
 ```
 
 For published stale builds, the report prints the `pkg_additional_info.yaml`
-build-number snippet, a `mutex_package: build_number:` bump (re-publishes the mutex
-with new constraints without changing its version), and the `anaconda remove`
-commands for the old files.
+build-number snippet and the `anaconda remove` commands for the old files.
 
 ## Bump vinca or rattler-build
 

.github/workflows/testpr.yaml

@@ -65,6 +65,8 @@ jobs:
           cache-write: false  # the build jobs save the pixi environment cache
       - name: Sanity checks (every distribution assembles, generated files up to date, sorted)
         run: pixi run rs check
+      - name: Unit tests of the tooling
+        run: pixi run test
 
   build:
     needs: plan

README.md

@@ -71,7 +71,7 @@ combines the two, and the files next to each:
 - **`vinca.yaml`:**
   - The package selection (`packages_select_by_deps`) lives in `shared/` for every distribution; vinca skips packages a distribution's rosdistro doesn't have.
   - Exceptions, in `shared/` or a distribution: `packages_exclude` (not built, dropped from other packages' dependencies) and `packages_skip` (not built, dependents keep the dependency), each as plain names or under `- if: <condition>`. ROS packages mapped to conda-forge in `robostack.yaml` are skipped automatically.
-  - `mutex_package`: name, `upper_bound` and the common `run_constraints` are shared. Each distribution sets its own `version`, and its `run_constraints` replace the shared constraint on the same package (e.g. jazzy's `libprotobuf 7.35.*`) or add new ones.
+  - `mutex_package`: name and `upper_bound` are shared; each distribution sets its own `version`. The mutex only keeps one distribution per environment and has no `run_constraints` (`rs check` enforces it): library versions come from the packages' own dependencies, and wrong ones are fixed in the package's metadata.
   - Other keys come from the distribution if it sets them, else from `shared/`. A distribution that differs from a shared setting just sets it.
   - Paths are relative to the file that sets them. `distros/<distro>/work/vinca.yaml` (generated) extends the distribution's file and adds `skip_existing` (its channel).
 - **`pkg_additional_info.yaml` and `patch/dependencies.yaml`:** merged per package. The distribution's keys win, for example its own `build_number` on top of a shared `additional_cmake_args`.
@@ -127,7 +127,7 @@ of a distribution uses `full_rebuild: true` there. A new build number goes into
 | `add-package <pkg>... [<distro>...]` | anyone | Adds ROS packages to the shared selection in `shared/vinca.yaml`, in sorted position; every distribution that has them builds them. Opens a PR listing, for the given (default: every) distribution, what will be built on linux-64 (and what is already published as a dependency). Valid ROS package names only, at most 10 per request. |
 | `update-rosdistro-snapshot [<distro>... \| all]` | maintainers | Snapshots the distribution's latest rosdistro sync (the release team's tag, e.g. `jazzy/2026-10-05`, recorded as `rosdistro_sync` in `distro.yaml`; rosdistro master for `rosdistro_sync: manual`, like rolling), then sets `build_number` to the highest build of the distribution's released packages + 1, bumps the mutex minor version and removes all per-package build numbers: a full rebuild. The PR links the sync's announcement and lists the version bumps. Runs daily for distributions with a new sync. |
 | `find-stale-packages [<distro>... \| all]` | maintainers | Published packages built against pins that no longer match, with the build-number snippet to rebuild them. Replies only. |
-| `update-conda-forge-pinning [<distro>... \| all]` | maintainers | Moves the distribution's conda-forge pinning (`conda_forge_pinning_version` / `conda_forge_migrations` in `distro.yaml`, or `shared/pinning/conda_forge.yaml` for distributions that follow it) to the latest version, with the migrations that are done for the distribution's dependencies, and re-renders `conda_build_config.yaml`. Only packages that use a changed pin, and everything depending on them, are rebuilt (per-package build numbers, a new build of the mutex at the same version); more than half affected means a full rebuild. Mutex `run_constraints` of the form `<pkg> <version>.*` follow the new pins. The PR lists the rebuilt packages, the migrations used and those waiting for feedstocks, and the dependency check; it is labelled `dependency-conflict` when the pins can't be installed together. Runs daily, one PR per distribution. |
+| `update-conda-forge-pinning [<distro>... \| all]` | maintainers | Moves the distribution's conda-forge pinning (`conda_forge_pinning_version` / `conda_forge_migrations` in `distro.yaml`, or `shared/pinning/conda_forge.yaml` for distributions that follow it) to the latest version, with the migrations that are done for the distribution's dependencies, and re-renders `conda_build_config.yaml`. Only packages that use a changed pin, and everything depending on them, are rebuilt (per-package build numbers); more than half affected means a full rebuild. The PR lists the rebuilt packages, the migrations used and those waiting for feedstocks, and the dependency check; it is labelled `dependency-conflict` when the pins can't be installed together. Runs daily, one PR per distribution. |
 
 There are three ways to trigger a command:
 - a *Package request* or *robostack-bot command* issue;

distros/humble/vinca.yaml

@@ -7,9 +7,9 @@ rosdistro_additional_recipes: rosdistro_additional_recipes.yaml
 build_number: 20
 
 mutex_package:
+  # new build without run_constraints (same version as the published ones)
+  build_number: 21
   version: "0.10.0"
-  run_constraints:
-    - krb5 1.22.*
 
 packages_exclude:
 

distros/jazzy/vinca.yaml

@@ -9,31 +9,9 @@ rosdistro_additional_recipes: rosdistro_additional_recipes.yaml
 build_number: 25
 
 mutex_package:
+  # new build without run_constraints (same version as the published ones)
+  build_number: 26
   version: "0.19.0"
-  run_constraints:
-    - libprotobuf 7.35.*
-    # ffmpeg (pulled in transitively by libopencv, needed by the whole image/gz
-    # stack) only supports libprotobuf 7.35 via libopenvino-tensorflow-frontend
-    # >=2026.3.0; older libopenvino/libopencv/ffmpeg builds still coexist in the
-    # channel needing libprotobuf 6.x, so pin this directly rather than relying
-    # on resolvo to find the compatible combination on its own. libopencv/
-    # py-opencv are pinned too, since resolvo has shown trouble propagating the
-    # openvino constraint transitively through ffmpeg on its own.
-    - libopenvino-tensorflow-frontend >=2026.3.0
-    - libopencv >=5.0.0
-    - py-opencv >=5.0.0
-    # Belt-and-suspenders for the same conflict: ffmpeg 8.1.2 builds that pull
-    # in the protobuf-6-only openvino also coexist in the channel. Pinning
-    # ffmpeg directly to major version 9 removes the ambiguity outright.
-    - ffmpeg 9.*
-    # libopencv 5.0.0 also depends on a *second*, separate openvino frontend
-    # package (tensorflow-LITE-frontend, distinct from tensorflow-frontend
-    # above) and every 5.0.0 build hardcodes it to the 2026.3.0.x line. Some
-    # ffmpeg 9.0.1/9.0.2 builds instead need 2026.3.1, which conflicts --
-    # constrain lite-frontend to the same range libopencv needs so resolvo
-    # picks an ffmpeg 9.x build compatible with it.
-    - libopenvino-tensorflow-lite-frontend >=2026.3.0,<2026.3.1.0a0
-
 
 packages_exclude:
 

distros/lyrical/vinca.yaml

@@ -6,13 +6,9 @@ rosdistro_additional_recipes: rosdistro_additional_recipes.yaml
 build_number: 27
 
 mutex_package:
+  # new build without run_constraints (same version as the published ones)
+  build_number: 28
   name: ros2-distro-mutex
   version: 0.21.0
   upper_bound: x.x
-  run_constraints:
-    - libboost 1.90.*
-    - libboost-devel 1.90.*
-    - pcl 1.15.1.*
-    - libprotobuf 7.35.1.*
-    - vtk 9.7.0.*
 

distros/rolling/vinca.yaml

@@ -7,29 +7,9 @@ rosdistro_additional_recipes: rosdistro_additional_recipes.yaml
 build_number: 29
 
 mutex_package:
+  # new build without run_constraints (same version as the published ones)
+  build_number: 30
   version: "0.22.0"
-  run_constraints:
-    # ffmpeg (pulled in transitively by libopencv, needed by the whole image/gz
-    # stack) only supports libprotobuf 7.35 via libopenvino-tensorflow-frontend
-    # >=2026.3.0; older libopenvino/libopencv/ffmpeg builds still coexist in the
-    # channel needing libprotobuf 6.x, so pin this directly rather than relying
-    # on resolvo to find the compatible combination on its own. libopencv/
-    # py-opencv are pinned too, since resolvo has shown trouble propagating the
-    # openvino constraint transitively through ffmpeg on its own.
-    - libopenvino-tensorflow-frontend >=2026.3.0
-    - libopencv >=5.0.0
-    - py-opencv >=5.0.0
-    # Belt-and-suspenders for the same conflict: ffmpeg 8.1.2 builds that pull
-    # in the protobuf-6-only openvino also coexist in the channel. Pinning
-    # ffmpeg directly to major version 9 removes the ambiguity outright.
-    - ffmpeg 9.*
-    # libopencv 5.0.0 also depends on a *second*, separate openvino frontend
-    # package (tensorflow-LITE-frontend, distinct from tensorflow-frontend
-    # above) and every 5.0.0 build hardcodes it to the 2026.3.0.x line. Some
-    # ffmpeg 9.0.1/9.0.2 builds instead need 2026.3.1, which conflicts --
-    # constrain lite-frontend to the same range libopencv needs so resolvo
-    # picks an ffmpeg 9.x build compatible with it.
-    - libopenvino-tensorflow-lite-frontend >=2026.3.0,<2026.3.1.0a0
 
 packages_exclude: