I'll mirror a discussion from Staging:K here as the comments will be lost once it is accepted.
can't install python-kdebase4-4.11.22-9.23.x86_64: package python-kdebase4-4.11.22-9.23.x86_64 requires python-kde4 >= 4.14.0, but none of the providers can be installed nothing provides python2-sip(api) = 12.1 needed by python- kde4-4.14.3-8.3.x86_64 (we have python2-sip-4.19.3-14.1.x86_64)
This is a bogus error: first, it's 'nice to have' that non-ring stuff does not break - but seeing > 150 build fails, we are clearly not there.
And even more importantly: once python-kde4 is rebuilt against python-sip's upgrade, the dependency will be corrected - so we really need to have some better logic here than blocking ring packages for non-ring issues that are no issues.
(as a workaround I linked python-kde4 into K:DVD, where we luckily can build it and thus 'prove' to repo-checker, that the issue is not real.
python-kdebase4 is provided by kdebase4-workspace which is a ring package hence why the message was included. The fact that a ring package has an install-time dependency on a non-ring was the entire point of my email to opensuse-releaseteam. This would not work for build-time requirements and why it is arbitrarily allowed for install-time seems more like an accident since the previous repo-checker did not properly review the stagings. The filtering can be restricted to just the packages updated in requests, but even then if kdebase4-workspace was updated this error would be rightfully shown. There is no magical way for an automated tool to know that this will be resolved once the updates are merged into the target project. If we are depending on that workflow why bother staging things anyway?
The proper solution is to include install-time dependencies of ring packages in the rings. The rings are already a giant short-cut that is a compromise for speed rather than correctness. The lack of install-time dependencies is really an issue. Some of them can probably be eliminated through re-packaging, but this is just not correct.
I understand that the rings are not shipped to end-users, but the entire point is to provide a subset of packages and verify that they are not broken by updates. The fact that the new tool correctly analyzes staging projects as a whole, just as a single build failure will block the entire staging, is a case of do not blame the messenger for a sketchy practice. If the package in question was to be installed for an openQA test it would crap during installation.
Any other solutions are just ways of hiding the errors and crossing our fingers that they will not exist once merged. The only real solution is including install-time deps in rings.
In fact any package checked on `openQA` already includes install-time dependencies. Simply inconsistent since nothing complained before.
`ghc-*` packages in adi stagings having to include all the other ghc packages to have the requires properly rebuilt is another example. That is the correct way to handle such packages and it would have to be an exception if the `repo- checker` was hacked for letter staging screwy ring practices. When you start adding exceptions that is usually a sign you are doing something wrong.