On Saturday, August 5, 2017 5:41:09 AM CDT Adam Majer wrote:
On 08/05/2017 12:34 AM, Jimmy Berry wrote:
Both to provide a grace period and tooling improvement going forward the tool will now regularly post comments on packages with issues in their corresponding devel project. The 112 comments went out Wednesday on a variety of packages. Thanks. This is good way of getting attention.
Sometimes the comments are in the wrong package. For example, I've noticed boost is on there, but the problem is with OpenMPI being broken. I'm not sure if this is by design or in error, but it risks spamming lots of packages just because innermost dependency is uninstallable.
I did consider this, but decided to go with the simplest approach first. Note that the relevant error is also posted on the openmpi package. It does not seem completely wrong since the error in fact effects a boost sub-package as well. It seems like maintainers might want to know that their package's dependencies are broken as that effects the usage of their package. It would be possible to build a tree and detect the root of the problem and only post there, but that would require parsing the details of these errors. Currently, the install check and file conflict tools do not provide structured output so parsing must be done in addition to mapping the binaries back to the packages from which they originate. Long story short, the new tool should prevent the majority of such issues from ever making it into Factory which should make these devel project comments rare. If it turns out to be otherwise or worth the extra effort it can be done. My hope is that maintainers simply fix these issues prior to wanting to update their packages since they do effect users. In the future such problems should only make it into Factory due to updates in separate stagings being accepted in one round and introducing a problem or due to more complex packaging relationships which are not seen during the staging process.
It's still better to know earlier rather than later. Currently these problems were only discovered by end-users.
Indeed. The semi-regular emails to Factory regarding such issues will hopefully decrease.
The new repo-checker is currently soft-enabled for Factory in that it will be checking all requests, but only commenting when it sees a problem and having no effect on reviews. On August 14th all new requests will require approval from the new repo-checker user on OBS.
In this case will this block something like boost because OpenMPI is uninstallable?
Yes. Obviously, the release team may choose to manually override, but the tool will not accept the review. Short of the recent introduction of parsing the output it was impossible for the tool to even know the package to which the errors related much less the source of a tree of problems (see above). Since these are in fact real problems I would like to see them simply resolved rather than avoiding them. Most of these problems are relatively simple to fix, but are not always noticed. The idea behind this being that if build time requirements were not capable of being met (even if another package's fault) those would block an update from entering Factory. Enforcing install time requirements has been the goal of the previous tool and this is simply bringing it closer to reality.
- Adam
For some examples see the issue referenced in the original mail for a list of SRs I created to fix a number of file conflicts. For details on the parsing and mapping of binary to package see the PR that added the devel package comments [1]. [1] https://github.com/openSUSE/osc-plugin-factory/pull/1042 -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org