Rollback limits for RPM schema changes in Fedora

Goal: ensure that after rolling back an ostree commit that includes an RPM database schema change, application data in mutable directories remains compatible with the older schema. Constraint: ostree only reverts the immutable OS tree; /var, /etc, /home are not rolled back, and SELinux contexts persist, which can cause mismatches if applications expect the old RPMdb version.

Uncertainty: there is no documented mechanism to automatically migrate or validate mutable data against the downgraded schema, leaving administrators to handle potential incompatibilities manually. Questions: What tools or practices can detect schema‑incompatible data after a rollback? Should ostree offer an optional snapshot of mutable state for selective revert? How can administrators test compatibility before committing to a rollback?