## Problem The p2 Planner - which computes the set of installable units (bundles/features) for an install or update operation - has no concept of the OSGi "uses" constraint (see OSGi Core spec, "Package uses Directive"). As a result, in certain (comparatively rare, but not exotic) dependency situations, p2 can produce a profile/installation that *looks* consistent from p2's own point of view (every requirement is matched by some capability) but is actually internally inconsistent from a real OSGi runtime's point of view: it mixes two incompatible versions of the same package(s) across a dependency graph that a real OSGi framework could never resolve or run correctly. Typical trigger: two bundles import the same package family with differently scoped version ranges (e.g. one narrow, auto-generated range vs. one wide or open-ended range), while a new release of that package family becomes available. p2's SAT-based optimizer prefers "the highest available version" as a tie-breaker when nothing forces otherwise, but does this per-package, not per-uses-constraint-closure - so it can pick the new version for some packages of a family and keep the old version for others, silently, without any warning or error. Concrete, fully reproducible example (synthetic ASM 9.9.1 / 9.10.1 bundles): https://github.com/eclipse-equinox/p2/issues/1119 ## Impact - When this occurs, the resulting installation is broken in ways that are extremely hard to diagnose (no p2/OSGi error at install time; failures only surface later, at runtime, as `NoSuchMethodError`/`ClassCastException`/ linkage errors, or as install/runtime failures depending on which half-mixed package graph gets loaded). - It affects real-world RCP products and, at times, the Eclipse IDE/Platform itself, whenever a target platform/update site mixes bundle families with inconsistent version constraints across a release boundary (a routine and unavoidable situation for any actively maintained repository/target platform). - In practice, many of these situations are currently caught only because Ed Merks (individually) tracks and works around them across hundreds of downstream projects/products - this is not a sustainable mitigation and gives a false sense that "it mostly works". - Because the failure is silent at install time and depends on the exact version/availability history of the repositories involved, it is hard to reproduce, hard to bisect, and hard to put a number on - by the time you can precisely estimate the fix effort for a specific occurrence, you have typically already spent that effort. ## Current state of investigation A first root-cause analysis and a working prototype exist: - The bug reproduces deterministically in a small, fully offline synthetic test (no network access needed), confirming this is a structural gap in p2's optimizer/solver, not a metadata quality issue. - A validation "oracle" was prototyped that reuses the real, standard OSGi resolver (`org.osgi.service.resolver.Resolver`, backed by Felix's resolver embedded in `org.eclipse.osgi`) to authoritatively detect "uses" constraint violations in a p2-computed candidate solution. - A first CEGAR-style retry loop (solve -> validate against the oracle -> if inconsistent, forbid the offending candidate -> re-solve) was wired into p2's SAT-based solver (`Projector`) and successfully resolves the reproduction case without regressing existing planner test coverage. This is a promising direction, but only a first prototype: performance impact (re-invoking a second resolver per solve) has not been measured, only one isolated reproduction scenario has been tested, the real OSGi resolver's own suitability/robustness as an embedded validation oracle inside p2 is unproven at scale, and the IU-to-OSGi-Resource conversion used for the oracle would need to become a proper, maintained part of p2 rather than a prototype adapter. Turning this into a production-quality fix - or exploring alternative resolution strategies - is a non-trivial, open-ended effort. ## Ask Given that the p2 Planner and the OSGi Resolver are foundational to the Eclipse Platform (and to every RCP product built on it), we would like the IDE Working Group to consider "p2 Planner / OSGi Resolver consistency and general resolver improvements" as a candidate topic for prioritized, dedicated development funding - to move this from an individually investigated prototype to a properly engineered, tested and maintained fix. Reference: - https://github.com/eclipse-equinox/p2/issues/1119 - https://github.com/eclipse-equinox/p2/pull/1122