[CentOS-devel] mock using yum .repo file?

Sun Jul 24 19:14:48 UTC 2011
Ljubomir Ljubojevic <office at plnet.rs>

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.

-- 

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant