https://bugzilla.redhat.com/show_bug.cgi?id=2126943 --- Comment #15 from Petr Pisar <ppisar@xxxxxxxxxx> --- It would make sense and I asked for it RPM developers some time ago. (I cannot a link now.) But the idea was rejected with an explanation that there are actually two kinds of run-time dependencies. One is RPM package-level dependencies specified explicitly in a spec file. Another is dependencies generated from the packaged files. The later dependencies coming from a file are tight to the file in the RPM package metadata. Why to distinguish the two? A catch is that when installing a package, an rpm tool can actually exclude some files from the installation (e.g. documentation or localization files). In that case a dependency tight to the uninstalled file will actually disappear from the installed package because the file simply is not installed. Hence RPM developers did not supported the idea of removing the less specific dependencies. Instead they recommended augmenting the dependency generator which scans the files (perl-generators) and conveys the discovered file-level dependencies to an rpmbuild tool. Alas, this idea was never implemented. (A spec file would pass a list of more specific versions to the generator through positional arguments defined with a macro.) Hence we ended up with filtering the dependencies at build time. Another approach could be minimizing the dependencies when gathering YUM metadata from the RPM packages. That could be doable. At the end, both metadata and DNF do not distinguish between the two kinds of dependencies. But I never got to requesting this feature to createrepo_c tool which generates YUM metadata. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2126943 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
