Jesse Keating wrote : > Yes, difficult thing to think of. Perhaps it would be feasable for the > master mirror to hold the correct headers/ file that has SRPMS and debug > stuff, but have a mirror.headers/ directory that is the result of > ignoring the SRPMS and the debug stuff. I personally don't wish to > include debug stuff. If the end user wants debug, they can download the > SRPM and build it themselves. But a headers/ and a headers.nosrpms/ > would be useful for mirror folks. Well, currently, the (yum) headers for SRPMS are not used for anything AFAIK. And as for having them included on a single config line along with the binary packages, it may be better to have exactly the opposite. With apt for instance, you're much better off not having "rpm-src" lines enabled in your configuration if you don't plan on using "apt-get source" very often. You save bandwidth as well as execution time. Anyway, wouldn't it be better to directly concentrate on the integration of the new common repodata files? The logical evolution is that it'll become the main supported server-side metadata format, so IMHO it's the most important to start thinking of now. How will it handle binary vs. source sets of packages? AFAICT, it doesn't make any special difference between both, but as I said above, it may be interesting to decide to separate them if it can lower to amount of transfered data when minor changes occur (e.g. one new update). I think the solution I like most is : [...]/SRPMS/repodata/ [...]/SRPMS/*.rpm [...]/$basearch/repodata/ [...]/$basearch/*.rpm With a default configuration which only fetches metadata for $basearch packages but with the ability to easily enable fetching it for source packages too. Just as you said concerning the debug packages, that very few people actually need them, the same applies (in a different proportion) to source packages IMHO. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2163.nptl Load : 0.10 0.48 0.56
