FBA — New look, new sections and other reports enhancements
During the last months we have added a lot of reports to our site http://fba.rosalinux.ru which is used to monitor ROSA repositories. It became very simple to get confused among all that reports, so we reorganized the main menu:
There are different reasons for ROSA repositories to have a lot of packages with the same Provides records. Some of such cases are valid, but sometimes such alternatives are excessive and just confuse users who receive a number of questions about packages they would like to install to satisfy one or another dependency. Unfortunately, in the past we didn’t pay much attention to a great amount of alternatives. As a result, not all packages with identical Provides records are really alternatives from functional point of view. Sometimes this comes from historical roots, sometimes it is a result of incorrect work of dependences generator, and sometimes such cases appear due to the maintainers mistakes made through lack of attention when the forming set of dependences. As a result, in case of wrong choice of alternative, installed applications don’t work and lead to the errors like this.
So far dubious and incorrect alternatives were detected and corrected occasionally — when maintainers faced conflicts personally or when we received corresponding requests from user. But now we have added necessary analytical means to FBA (thanks to urpm-repograph which already provides all required functionality), so now ROSA repositories are subjected to constant monitoring of packages with identical Provides.
Results of monitoring can be observed there — http://fba.rosalinux.ru/test/repomanage_alternatives/.
If you think that some alternatives should be removed — feel free to send your suggestions to our developers :) Of course, some duplications are legitimate. In future we will separate such cases not to treat them as errors.
Besides of adding new reports, we are working on improving the existing ones. Now at various pages you can get not only the name of the package which contains errors, but also get a list of packages that depend on the broken one. It is really actual for repository closure analysis: if some package cannot be installed because of unsatisfied dependences, then dependent packages also cannot be installed. That’s why it is important to estimate the number of packages that will be «lost» for user as a result of dependency breakage. For example, in repoclosure reports you can jump to the «Broken Packages» table. For every broken package, it provides the number of packages that depend on it. Click on that number to get a list of such packages. A «question» mark instead of a number designates that there is a newer version of this package in repository. So no package depends on this particular version.
Finally, there is one more useful improvement: now the names of SRPM packages in repoclosure reports are links to the appropriate projects in ABF. So you can go from the report page straight to the page of the project in ABF (moreover, necessary Git-repository branch will chosen automatically).