Reviving this thread. I have had success with this project implemented
as a mock plugin [1] (available in copr: [2]). I intend to communicate
with mock developers to see if it can be integrated into mock [3].
Implementation notes aside, this may be a good place to discuss the
algorithm:
On input we have the *.src.rpm file(s) and a list of files that have
been accessed during the build.
* From the source RPM we extract the BuildRequires strings.
* Then we use `dnf --installed --whatprovides $BR` to see what RPM
provides each BR. This itself presents an interesting question: what
does it mean if a single BR is provided by multiple installed RPMs? We
assume it must be because some of them must have been required by
different packages.
* For each such RPM we query `dnf --assumeno remove $RPMS` to see what
packages would have been removed.
* For each RPM that would have been removed even transitively we query
what files it contains and check whether its files have been accessed.
If not, it is added to the list of RPMs that can be removed.
* The next `dnf --assumeno remove $RPMS` query is run with RPMS
containing all the previous RPM that we concluded we can remove as well
as the one from current iteration.
This is a conservative approach that will not include false positives.
However it will not warn about cases when the package has a BR on `foo`,
`foo` requires `bar`, `bar` is really needed but `foo` is not. This
would require actually traversing the dependency graph manually, which
is possible but needs implementation.
[1] https://github.com/mkoncek/unbreq
[2] https://copr.fedorainfracloud.org/coprs/mkoncek/unbreq/
[3] https://github.com/rpm-software-management/mock/issues/1562
On 5. 7. 2024 11:23, Michael Schwendt wrote:
On Wed, 3 Jul 2024 18:02:01 +0200, Marián Konček wrote:
To my knowledge there is no such project.
Only highly experimental ones have been used many, many years ago. For
example, in Fedora land I've caught some unused BuildRequires with a
script that checks whether shared libs provided by build dependencies
reappear as SONAME deps in the built packages.
--
Marián Konček
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
