Since the issue of how to deal with "leaky rings" keeps manifesting itself in different forms it seems like another attempt at explaining why this happens, what are the options, and why changing the ring policy is the best choice seems worth the effort. The fundamental difference between adi stagings and letter stagings is that adi build the request packages directly on top of Factory whereas letter stagings also include all ring packages. The partial exception being ghc-* packages in which all other ghc-* packages are inherited into the adi staging. Previously, the repo_checker would review packages from devel projects which built against Factory. This meant that the check was essentially the same as the repo_checker checking adi stagings with the exception that the majority of the time it would review requests individually instead of grouped. With the new repo_checker reviewing stagings (since after all the entire staging process exists) all adi packages are reviewed essentially the same other than any non-submitted/grouped devel package changes are excluded as they should be. The major difference occurs in how ring packages are reviewed since they are reviewed along with all the other ring packages at the point which they were last rebased. The various problems stem from: - changes that cause install-time dependency issues until rebased - updates to ring packages that require non-ring packages to be rebuilt The second issue can take two primary forms: 1) a package (such as a pattern) that has a Requires on a non-ring package and no BuildRequires on that package 2) a multi-spec package which does not build all subpackages in rings, but has exact version requirements on the root package Both of the two core issues stem from the fact that rings have all BuildRequires satisfied within the rings, but not all Requires satisfied withing the rings. In the majority of cases seen the issues would be resolved once the packages were accepted into Factory and the non-ring packages rebuilt. This certainly is not guaranteed to always be the case and as I have said before seems rather arbitrary to draw the line at that point. The root concept of rings seems to be a subset of packages that are "important" that are rebuilt to try and ensure they are not broken by updates to other "important" packages. As such the whole idea (as is enforced with BuildRequires) is that they are self-contained. The proposed workarounds are as follows: - enhance manual whitelist workflow to be staging specific and clear on accept - ignore all errors caused by non-ring packages Interestingly, both of these problems are resolved by simply requiring the rings to have self-contained Requires just as they already have for BuildRequires. Given the alternative is ignoring the problems either via manual or automated means the result is virtual finger-crossing assuming the errors will be resolved once merged into Factory. Being certain and consistent seems like a much better strategy than hoping for the best and looking the other way. For whatever reason there seems to be disagreement on this point even though it is the root cause of all these issues. The alternatives are a fair bit of extra work either on the part of Factory staging masters and to automate ignoring the problems and lower the confidence that the result is correct. As you are probably already aware I am never in favor of adding manual steps where they can be avoided so "enhancing" the whitelist feature which was intended to be temporary is the complete wrong direction from my view. Given the strong resistance to fixing the rings to make them consistent and correct I will cover the possible alternatives for automation. The biggest hurdle is the lack of structured output from the install check and file conflict tools. During the rewrite I added some basic parsing to be able to report problems on devel packages, but that parsing only looks at which packages are effected by the issue not at the details of why. Given the variety of forms and complexity of reasons parsing the text would seem less than ideal. The alternative is reworking those tools to provide structured output that can be interpreted by the repo_checker. As Ludwig already indicated upstream does not have interest in such changes and suggested we rewrite the tools as needed (and thus also maintain such changes). Assuming we had that structured output an error for a ring package caused by a non-ring package could be ignored. Obviously, the repo_checker has no way to know if this will actually be resolved on merge or if it is a real problem. Basically if any package listed in the detailed section is a non-ring package ignore the error. At this point it seems like even bothering to layer the letter stagings on top of Factory is then pointless if all the errors produced are then ignored. Interestingly this would effectively treat the letter stagings as contained units...since that is really what they want to be and how the staging masters want the repo_checker to treat them. Really begs why we just don't make it so. The other questionable area is how to treat file conflicts with non-ring packages as again they may be real, but may be resolved on update...there really is not any way for repo_checker to know. Hopefully, this makes it clear why it makes far more sense to make the rings consistent and be self-contained not just for BuildRequires, but Requires as well. The alternatives are extremely sub-optimal and require a lot of effort while never achieving a high level of confidence in a correct result. Having self-contained rings however achieves both. -- Jimmy -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org