#2032 please list broken deps at the top of the rawhide report
Closed: Fixed None Opened 14 years ago by alexlan.

I had requested this some time back, to increase the visibility of the broken deps so that Fedora maintainers could work together collectively to spot major API breakage/cross-distro package issues, rather than being buried (and therefore ignored) at the end of the list of updated packages.

http://www.redhat.com/archives/fedora-devel-list/2008-March/msg00068.html

For a while Jesse did this manually, but it has now reverted to being at the bottom again. Suggestion here:

http://www.redhat.com/archives/fedora-devel-list/2008-March/msg00678.html

was to have the following order:

  • new packages
  • broken deps
  • changes

which seems sensible to me.

If you can point me to the source that generates the report, I'll look into writing some patches.


The new packages changes come from the same script, where as the depcheck comes from a different script. The best I can do is put the dep check first, then the changes after it.

I disagree that just moving broken deps at the top of the rawhide report is a good solution. First of all, this change was not announced and therefore broke peoples expectations. At least someone else and me thought that there are now new packages, because we did not bother to scroll beyond the broken dependencies.

Also the current report is not very useful. It does not show, whether the package is broken for a longer period of time or only just now. Since the package maintainers will also get a personal e-mail, it is not even worth to go through the list to see, if there are some packages that one owns in the list. The list also contains a lot of broken dependencies that are there for a longer period and that is already worked on (the clutter stuff), so these should be less prominent in the report.

How about another approach for this and use bugzilla to track long term broken dependencies. E.g. if the report script notices, that there is a broken dependency, it first checks, whether this is might be a new broken dependency, e.g. if the package was also updated within the push or a package that provides a package that the package depends upon is updated, then the broken dependency is considered to be new and the maintainers are only noticed via e-mail. If the broken dependency is not new, then a bug report on Bugzilla is created, if there is none already, and the progress can be tracked. The script could then also report these bug reports according to their activity / staleness. So that there is e.g. a warning if a bug was not touched for X days. So then superpackagers can start to work on fix these packages.

In conlusion, I guess if the information is helpful to fix the broken dependencies, then they will most likely be less ignored. Btw. is there a mailing list to reach all superpackagers? Then maybe the report could also go there, because afaik normal packagers cannot fix these packages anyhow.

When this was tested months ago, there was no feedback other than the one person requesting the change, so the change was made. If you'd like further changes to how the report looks, I'll review any patches sent my way.

"superpackagers" are expected to be on fedora-devel-list and if they do care about fixing the status of trees, they'll consume the broken deps report. Longer term, these types of tests will be handled by the autoqa system which can and will include bug filing for broken deps.

Login to comment on this ticket.

Metadata