On Wed, 2017-08-30 at 10:21 -0500, Jimmy Berry wrote:

It appears that in order to workaround the intermittent false- negatives emitted by repo_checker a number of patterns have been whitelisted. As an aside, during my requests for feedback about issues and manual accepts for previous repo_checker nothing was really mentioned although we have since come across several cases that would have been present previously as well. As in this case of working around an issue it would be preferred if a discussion is started rather than me having to stumble across such workarounds.

Currently whitelisted patterns:

patterns-base-apparmor patterns-kde-kde_telepathy patterns-media-rest_cd_gnome patterns-media-rest_cd_kde patterns-media-rest_dvd

Most can probably disappear already again - as they were temporarily needed (as an alternative to rebase a whole staging). Maybe we can have this kind of 'staging based, temporary ignores' as part of the project meta data the checker would take into account? Would be better than having a whitelist which I will keep forgetting to clean up.

This is certainly less than ideal as it means that any real problems will be ignored. In fact one of the oldest issues in against the repo_checker is in regards to packages reference by patterns being removed without any proper warning [1].

I tried to only add stuff which I understood when I saw them in staging (pattern-kde for example got updated, telepathy dropped, which meant the stuff in the existing stagings were no longer happy)

repo_checker acts like an extension of OBS in that OBS would check that the BuildRequires can all be met before attempting to build while repo_checker ensures the Requires can be met. Currently, anything added to the rings must have all of the build dependencies present. This has led to packages being split and all sort of fun stuff to avoid bringing in too many dependencies. At the end of the day, packages in rings are only passed because all their dependencies are also available in the rings.

I don't think every package in a ring has to be installable inside the ring. I can easily create a source package in ring0 that produces a FOO-doc package that has a Requires: texlive - yet, I certainly do not EVER want texlive in ring0. And as long as FOO has no build deps on texlive, there is no need to do so.

Contrast that to patterns which while having their minimal build dependencies present do not have there install-time dependencies present. That combined with the exact version Requires causes the repo_checker to correctly find that they are not installable from the letter staging. Not having the install-time requirements met within the staging seems like a short-cut rather than an idealistically correct setup. If patterns are of enough importance to be in the rings, their install-time requirements ought to be as well. Otherwise, it would seem logical to remove them from the rings since they really are not being checked as the primary purpose of a pattern is to pull in other packages which cannot be confirmed.

We care for SOME patterns - and the not for others.. the ones we care for are referenced by the testdvd creation script - and the kiwi file gets invalidated if the pattern is not installable.

Alternatively, not having the hard version requirements would remove the repo_checker errors, but still fail if packages required by the pattern are removed. Either way, from what I can tell this should really be a process change rather than either special-casing in repo_checker or whitelisting to hide the problem.

Most of the issues I'd seen around patterns in stagings is that things change in oS:F - and if the patterns are the only thing holding off repo-checker from passing it, I'm certainly not willing to rebase a staging and have it build a couple hours again. Hence back to the proposal: can we have the repo_checker exception for a staging project as part of the staging project directly instead of a global config ? Cheers, Dominique

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