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

Sun Jul 24 18:43:03 UTC 2011
Jeff Johnson <n3npq at mac.com>

On Jul 24, 2011, at 2:24 PM, Ljubomir Ljubojevic wrote:

> Jeff Johnson wrote:
>> 1) Yes, mock uses yum which will use repo files. You likely need
>> to configure up /etc/mock/* somehow … checking … yes stanzas
>> like this are merely yum repositories written differently:
>> 	[fedora]
>> 	name=fedora
>> 	mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-15&arch=i386
>> 	failovermethod=priority
>> See if someone hasn't configured up mock for cents somehow: that was the point
>> of my aside: its often quite mysterious how to find the right URI. I have difficulties
>> all the time.
>> 3) priorities don't work too well generally (but do work with specific usage cases).
>> The typical usage case for priorities is to set up a precedence order if/when
>> there are multiple choices for a package to install. I would always use
>> whatever is recommended by add-on repositories, and (if you intent is to become
>> an add-on repository using preferences) well Dag's repository uses priorities nicely
>> and flawlessly (from first hand experience) and is worthy of study. But you shouldn't
>> have to do too much with priorities, you will absolutely know when there is a need
>> to use, because your updates will be breaking, and your preference (which will determine
>> the priority field) will be clearer.
>> hth
>> 73 de Jeff
> 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 …

… again no fault intended: I am seriously interested in the objective
number for "engineering" and development purposes, not in criticizing.

> plc-os-on.repo:
> name=Spec CentOS-$releasever - os - $releasever - $basearch
> baseurl=http://xxx.wwwww.rs/mrepo/plc-centos6-$basearch/RPMS.os/
> gpgcheck=0
> enabled=1
> priority=1
> exclude=*releases
> All priorities in yum .repo files are carefully adjusted to not mess 
> with repos of higher value for me, but to also provide all available 
> packages.
> plnet-downloaded for example is repo with high priority and is populated 
> with carefully selected packages from other repos with lower priority 
> that conflict (like aTrpms and repoForge) and packages not available via 
> regular repositories but from download web pages (skype, shorewall, etc..).

This is the right approach: Get the priority metric approximately right,
and pperpare a layer to deal with the inevitable flaws (that come
from using per-repository, not per-package, "priority", a design flaw imho).

There's a better metric than "priority" that SHOULD be used. An integer priority is
fine if you just need some general means to order choices and do tie breaking.
The better metric would be "nearness", where the usual per-package choice would
be to
	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.

> "-off" at the end marks disabled repos. Those are all local repos and I 
> have URI's. But I am still modifying and selecting repositories and 
> packages. That is why I would like to use .repo files from 
> /etc/yum/repos.d/. So I do not have to worry if there were changes.

That's a sane idea (and related to "too many notes and not enough music"
with yum repositories and mock build targets being essentially the same info
but specified in multiple places).

73 de Jeff