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