#284: depcheck does not produce output for some pending updates --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink):
== Cause ==
This is due to the fact that yum is written such that the skipped package information is only made available when dependency resolving issues can be successfully resolved.
In the cases that we're seeing this, yum can't resolve the dependencies, doesn't update its public data structures and we don't find any information about the deps with problems.
yum-3_2_X head, line 1186 {{{ #!python if rescode != 1: self.verbose_logger.debug("SKIPBROKEN: took %i rounds ", count) self.verbose_logger.info(_('\nPackages skipped because of dependency problems:')) skipped_list = [p for p in skipped_po] skipped_list.sort() for po in skipped_list: msg = _(" %s from %s") % (str(po),po.repo.id) self.verbose_logger.info(msg) self.skipped_packages.extend(skipped_list) # make the skipped packages public else: # If we cant solve the problems the show the original error messages. self.verbose_logger.info("Skip-broken could not solve problems") return 1, orig_restring return rescode, restring }}}
== Root Cause ==
As far as I can tell, the root cause of this is feeding bad data into yum. I spent a lot of time with [http://autoqa.fedoraproject.org/results/92666-autotest/ job 92666] (depcheck, x86_64, F14).
This particular failure is interesting because the [http://autoqa.fedoraproject.org/results/92524-autotest/ same update passed on i386].
The problem is a conflict between how depcheck works and how the spec file for wine is written. {{{ Requires: wine-wow(x86-64) = %{version}-%{release} Conflicts: wine-wow(x86-32) = %{version}-%{release} }}}
Since we're trying to install both the 32 and 64 bit versions of wine on x86_64, yum can't seem to resolve a solution, fails and doesn't report the broken packages (apparently by design)
== Possible Fixes == This one is a little harder; I can't really think of a great fix ATM. The ones that I can think of are: * Request enhancement for yum to make skipped packages available on failure * I imagine that there is a reason this data isn't provided, though * Don't feed bad data into yum * The only way I can think of doing that in the case of 92666 is to pre-determine the conflicts on each package and exclude one of them from the 'install' set of pending and accepted packages. * I'd have to think that one through a bit more, not sure it's a good idea. * Assume no output is NEEDS_INSPECTION * Assuming FAILURE would cause a false negative in the case of job 92666 (and I assume others) * Assuming NEEDS_INSPECTION would at least let other packages get commented instead of crashing and stopping any bodhi updates * Blacklist the packages that are causing problems * flag them for manual testing?
Of these solutions, I think that setting the missing updates to NEEDS_INSPECTION is the best short term fix. It keeps depcheck from crashing as much and doesn't have problems with false positives or negatives. It would probably be an annoyance for the affected maintainers, though.
If we can figure out how to pre-parse the rpm data to form the install set, that should also work but I also think that might be more of a long- term fix.