Clint Dilks wrote:

...

If I add priority=1 to [updates] in CentOS-Base.repo when I run "sudo yum update" I get the warning 66 packages excluded due to repository priority protections

This does not seem to have any adverse effect, but what exactly does it mean?

See http://wiki.centos.org/PackageManagement/Yum/Priorities ( take a close look at section 5 )

Thanks for your response. I had actually read this section, but evidently do not understand it. I take it the 66 packages mentioned are in "unofficial" repositories, in my case rpmforge.repo.rpmnew ?

Generally all active repo's in Base would be given the same priority. If you have only added a setting of 1 for updates then all other repos will have a priority of 99 (lower).

I did realize that. But as far as I can see, the effect of the plugin is to disable all repositories with priority 99, or indeed with priority > 2 ?

I've presently disabled this plugin, since I don't see any rational way of using it.

On 08/15/2013 01:07 PM, Scott Robbins wrote:

On Thu, Aug 15, 2013 at 12:07:26PM +0200, Timothy Murphy wrote:

...

Clint Dilks wrote:

...

...

If I add priority=1 to [updates] in CentOS-Base.repo when I run "sudo yum update" I get the warning 66 packages excluded due to repository priority protections

...

...

See http://wiki.centos.org/PackageManagement/Yum/Priorities ( take a close look at section 5 )

Thanks for your response. I had actually read this section, but evidently do not understand it. I take it the 66 packages mentioned are in "unofficial" repositories, in my case rpmforge.repo.rpmnew ?

If you have a repo called something.repo.rpmnew, it will be ignored. You would have to rename it to something.repo.

To oversimplify, say that you have rpmforge, base, and epel repos. Say that all of them have versions of perl. However, these versions may conflict with each other and break things.

So, if you gave base and updates priority of 1, then the others, even if they have a later version of perl, won't install it. The downside is that you're running the older version. The upside is that you don't risk this newer version of perl breaking some other package that you'd forgotten.

There are disadvantages--as the wiki page in question mentions, the late Seth Vidal disliked it.

Warning: If you set priority of base repo to 1, and priority of updates repo (or all others) to 2, then packages in updates repository will be hidden. that is why it is so important to have same priority on both base and updates repositories.

Any package name that exists in 2 or more repositories will be hidden from repositories with higher number / lesser priority (just like those 66 in your case). Example:

httpd.x86_64 => ver. 2.2.15-26.el6.centos in base httpd.x86_64 => ver 2.2.15-28.el6.centos in updates httpd.x86_64 => ver. 2.2.15-29.el6.centos in updates

With priority plugin: base=1, updates=2 (or nothing) 2 packages excluded due to repository priority protections Available: httpd.x86_64 => ver. 2.2.15-26.el6.centos from base

With priority plugin: base=1, updates=1 (same priority) 0 packages excluded due to repository priority protections Available: httpd.x86_64 => ver. 2.2.15-29.el6.centos from updates

Timothy Murphy wrote:

But what if a package in rpmforge requires a newer version of a package that is available in rpmforge but not in updates? Surely this is very likely to happen?

If a package in RPMForge requires another package from RPMForge that doesn't conflict with a package from Base or Updates, then the second package will be installed.

If a package in RPMForge requires another package from RPMForge that _does_ conflict with a package from Base or Updates, then the second package won't be installed, and neither will the first package. That's what's supposed to happen.

By design, CentOS is a conservative and stable distribution. If you need the latest packages, CentOS isn't the right distribution for you.

Yves Bellefeuille yan@storm.ca