File Deps Guideline
Problem
Resolving file dependencies can be a bottleneck when running yum. With our current repodata format, information on which package owns files in /etc and the bin directories (/bin /sbin /usr/bin /usr/sbin) are kept in primary.xml. All other file deps are kept in filelist.xml. This means that anytime yum has to resolve a file dep in /etc or a bin directory it can just download primary.xml to resolve it. If the file dep is outside of those directories, yum has to download and parse a second xml file, filelist.xml, which is much larger than primary.xml.
Fedora 6 repodata compressed and uncompressed:
| primary.xml | filelist.xml | |
| Core | 1M/7.6M | 3.1M/39.2M |
| Extras | 4.7M/11.7M | 4M/50.8M |
| Updates | 0.4M/4.2M | 2.1M/27.5M |
The compressed size has direct bearing on the additional time it will take to download the additional filelist.xml. The uncompressed size is one indicator of how much additional time is needed to parse for the file that satisfies the dependency. If yum does not need to refresh its primary.xml and filelist.xml (because it downloaded a copy previously and the repository has not been updated since), yum won't have to parse a new file and the filelist info will be quicker to find (as the file will have been parsed into an sqlite database), however this is the exception rather than the rule.
If we can avoid having to download and parse filelist.xml, we can greatly speed up yum's dependency resolution times.
Proposed Guideline
SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. There are times when other technical considerations outweigh these considerations. One specific example is packages installing into %{_libdir}/mozilla/plugins. In this case, mandating a specific browser in your package just to own this directory could drag in a large amount of needless packages. Requiring the directory to resolve the dependency is the better choice.