Whether dnf does what yum does misses the point: Lazy downloading of file dependencies did not work then and does not work now. Here's why: The fundamental decision made by depsolvers is what packages are "newer" and need to be upgraded. When _ANY_ commonly used package has a file dependency outside of the paths chosen to be delivered in primary.xml, then _ALL_ file dependencies need to be downloaded in order to find the package that contains the path so that the upgrade decision based on "newer" can be determined by the depsolver. Without explicit packaging policy -- and tools to verify -- forbidding all file dependencies outside of the magical paths preselected to be included in primary.xml, then filelist.xml will surely **AGAIN** be downloaded **ALL** the time. Since every depsolver has chosen to implement the magical paths in code rather than sharing a list of file patterns permitted somehow, then this cycle will be repeated again and again. The new usage case of /usr/libexec, and the older usage case of /bin vs /usr/bin indicates that history is repeating itself. TL;DR Magic file path patterns implemented in code and lazy loading of filelist.xml "just in case" will never succeed. Even if you Get It Right! for Fedora (and CentOS) packaging policy, there will be issues with custom 3rd party and end-user repositories that do not conform to the magical paths chosen. It is also very not surprising that there are very few file dependencies remaining in Fedora after several jihads (and policy) to eliminate file dependencies in Fedora packages. Another jihad (and tighter policy) cannot solve the problem of custom non-policy-conformance in custom repositories, no matter what. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/KAOMH4Z2NMRZKIMXYP7DYBY3B7BN3AVM/
