On 3. 6. 2026 23:29, Miro Hrončok wrote:
On 02. 06. 26 15:02, Marián Konček wrote:
Hi, as the author of the `unbreq` Mock plugin, I found some time to
run a mass build on over 2200 packages that are part of the ELN
package set. 40 build failed or timed out, but I successfully built
exactly 2200 packages.
The report is here: https://mkoncek.fedorapeople.org/unbreq.html
...
Thanks. This is awesome.
Several notes about common Python cases:
(python3dist(tomli) if python3-devel < 3.11) is omnipresent -- if not
dealing with conditional buildrequires generally, consider filtering
this from the report. (Generally speaking, if the X package from (X if
Y) is not present at all, the BR should probably not be reported.)
A fix for this is on its way:
https://github.com/rpm-software-management/mock/pull/1757
We can assume mock installed all the necessary dependencies before the
build and if a rich dependency listed in the BuildRequires is not
installed (no installed RPMs provide it), then we can assume it does not
satisfy conditionals and can ignore it from the listing.
BuildRequires for Python extras, such as
python3dist(build[virtualenv]). Those are empty metapackages and files
from them are "not used". All such generated buildrequires are
accompanied with other BRs such as:
$ repoquery -q --repo=rawhide-source --requires python-setuptools |
grep build
python3dist(build) >= 1.0.3
python3dist(build[virtualenv]) >= 1.0.3
and hence reported as useless. They are not.
The resolution is done by attempting to remove each `BuildRequires`
field and checking files owned by all the RPMs that would have been
removed by the DNF transaction. I.e., if a package does not own any
files but depends (directly or transitively) on something that was used,
and was not needed by anything else, this will not be reported as unused.
Example: `make` depends on GCC, GCC was used (but not listed separately
as a BuildRequires), but make was not, unbreq evaluates that `make` was
*not* unused.
This could be handled more systematically, but we need to see some real
world cases first to improve it.
I guess that if the plugin works by checking if files are accessed,
any Python package that asks Python "what Python packages are
installed?" (== each Python package using %pyproject macros) will
access all the metadata files for all installed Python packages. Ergo,
if I understand this correctly, no Python package (except for the 2
cases mentioned above) will ever be reported as unused. Is that so?
Correct, that is why the plugin has an option `exclude_accessed_files`.
From Maven packaging I know that Maven, during its build reads all the
metadata files to create an association between artifact names and POM
and JAR files. This configuration option tells the plugin to ignore
matching files.
As I mentioned my mock config contained this:
config_opts['plugin_conf']['unbreq_opts']['exclude_accessed_files'] = [
'^/usr/share/maven-metadata/',
'^/usr/lib/.build-id/',
]
I did not yet analyze how other build systems handle this but I would
add more filters as soon as I discovered them.
--
Marián Konček
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
