Le 2018-08-28 15:00, Nico Kadel-Garcia a écrit :
And no, I'm afraid it does *not* scale since the exclusions from another repository may not be appropriate to the repository one is currently building, and automatically including that whitelist is automatically mismatching the content database to the actual content of the repository *every time*.
The whole point is to separate the file indexes in two files, one downloaded by default the other as-needed.
It is trivially obvious that putting automatically the file deps the repo uses itself in the first index cuts down drastically on the situations when you need to download the second index file (only needed to handle the situations when the user explicitly requests a file dep not used by the repo itself, or when resolving for a third party package). We know the number of file deps used by our repos is small, as they are used for special cases, so it's not as if putting all of them automatically in the first index is going to bloat it.
It is trivially obvious than when a repo, is intended to be used on top of another repo (fedora updates over fedora, epel over centos), you want to extend this file to the file deps, referenced by this other repo, so you need to point createrepo to this (or these) other repo indexes to check what they need (and save in the repo metadata the list of the file deps it uses, but that's trivial if you do the first step and this list would be only downloaded by createrepo, not the average dnf user).
And doing the second part requires passing an explicit parameter to createrepo because it can not guess that inheriting centos rules for epel is appropriate. But the person indexing epel bloody well knows it is appropriate.
That's the basic idea. One would probably want to handle BR file deps too to cut down on build farm processing times, that requires pointing createrepo to the SRPM repo metadata.
Regards -- Nicolas Mailhot _______________________________________________ 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
