<p>I remember a discussion about potential checks that could help identify problems caused by package upgrades, but problems occurring with other packages rather than the package being upgraded. If we had such automation, it would prevent problems like this one from happening in the future.</p>

<p>The basic plan would be:</p>
<p>- establish a list of packages potentially affected by the planned upgrade<br>
- run checkpkg against this set of packages and record all non overridden errors thrown by checkpkg. The set of packages should not include the packages from theplanned upgrade.<br>
- run checkpkg again, against a slightly modified set of packages: this time include the new versions of the packages to upgrade<br>
- if any new errors are thrown, it means that our upgrade breaks other packages and it should be stopped.</p>
<p>I'm sure there's a fair amount of devil to be in the details, but this check looks doable to me. I don't have ideas what false positives would we get from it. They would be hard to override, especially if they concern legacy packages.</p>

<p>This mechanism would be best a wrapper around checkpkg. I don't want to add more functionality to the core checkpkg executable unless really necessary.</p>
<p>If anyone is up for implementing this functionality, I'll be happy lend a hand and show where to get resources, e.g. json catalog representations. </p>
<p>Maciej</p>