Jeff Johnson wrote:
On Jul 24, 2011, at 2:24 PM, Ljubomir Ljubojevic wrote:
I use following repos:
playonlinux-on.repo plc-adobe-linux-on.repo plc-atrpms-stable-off.repo plc-atrpms-testing-off.repo plc-c6-testing-off.repo plc-centosplus-on.repo plc-elrepo-extras-off.repo plc-elrepo-fasttrack-off.repo plc-elrepo-kernel.repo plc-elrepo-on.repo plc-elrepo-testing-off.repo plc-epel-on.repo plc-extras-on.repo plc-fasttrack-off.repo plc-kb-el6-ext-off.repo plc-kb-el6-ext-test-off.repo plc-kb-el6-misc-off.repo plc-kb-el6-misc-test-off.repo plc-os-on.repo plc-releases-on.repo plc-remi-off.repo plc-remi-test-off.repo plc-repoforge-buildtools-off.repo plc-repoforge-dag-off.repo plc-repoforge-extras-off.repo plc-repoforge-on.repo plc-rpmfusion-free-updates-off.repo plc-rpmfusion-free-updates-testing-off.repo plc-rpmfusion-nonfree-updates-off.repo plc-rpmfusion-nonfree-updates-testing-off.repo plc-sernet-samba-off.repo plc-updates-on.repo plc-virtualbox-on.repo plc-virtualmin-universal-on.repo plnet-archive-off.repo plnet-compiled-on.repo plnet-downloaded-on.repo plnet-releases-on.repo plnet-replace-off.repo plnet-test-off.repo
Eeek! You are already well beyond my expertise: that's a whole lotta repos.
You are likely paying a significant performance cost carrying around that number of repositories. Can you perhaps estimate how much that performance cost is? Say, how long does it take to do some single package update with only CentOS repositories configured all of the above configured I'm just interested in a data point to calibrate my expectations of how yum behaves with lots of repositories. You're one of the few and the brave with that number of repositories …
Take notice that only 16 are enabled, and ~24 are disabled by default and used only if I do not find what I am looking for.
Performance is not much of an issue, since the attributing factor is the number of packages in side those repositories. Biggest of third party repos are repoforge and repoforge-dag.
… again no fault intended: I am seriously interested in the objective number for "engineering" and development purposes, not in criticizing.
<snip>
Prefer answers from the same repository. A "nearness" rather than a "priority" metric starts to scale better. E.g. with a "priority" metric, adding a few more repositories likely forces an adjustment in *all* the priorities. There's some chance (I haven't looked) that a "nearness" metric would be more localized and that a "first found" search on a simple repository order might be sufficient to mostly get the right answer without the additional artifact of attaching a "priority" score to every package.
This is why I chose to create plnet-downloaded. Versions on useful packages are copied and their versions frozen with stable releases, and updated in bulk and controlled. Might be easier to just repac them and create separate repository.