On Jul 24, 2011, at 2:24 PM, Ljubomir Ljubojevic wrote:
Jeff Johnson wrote:
- 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.
- 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).
(aside) 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