Hi everyone,
This just came to my attention --- I have CentOS 7 installed on one machine, and have configured elrepo and epel as additional repositories. When I turned on the yum-priorities package (and set up priorities in the order base&updates < elrepo < epel), it turns out that there are 65 conflicting packages between base and epel, and additional 5 between elrepo and epel (there are no conflicts between base and elrepo, as expected).
As far as I understand, this shouldn't happen. Does anyone know which packages are conflicting, and why?
Here is the relevant yum output, note the excluded packages info:
# yum repolist Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * base: ftp.ines.lug.ro * elrepo: ftp.ines.lug.ro * epel: mirror.pmf.kg.ac.rs * extras: ftp.ines.lug.ro * updates: ftp.ines.lug.ro 70 packages excluded due to repository priority protections repo id repo name status base/7/x86_64 CentOS-7 - Base 8,652 elrepo ELRepo.org Community Enterprise Linux Repository - el7 143 epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 8,025+70 extras/7/x86_64 CentOS-7 - Extras 128 updates/7/x86_64 CentOS-7 - Updates 682 repolist: 17,630
# yum repolist --disablerepo=elrepo Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * base: ftp.ines.lug.ro * epel: mirror.pmf.kg.ac.rs * extras: ftp.ines.lug.ro * updates: ftp.ines.lug.ro 65 packages excluded due to repository priority protections repo id repo name status base/7/x86_64 CentOS-7 - Base 8,652 epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 8,030+65 extras/7/x86_64 CentOS-7 - Extras 128 updates/7/x86_64 CentOS-7 - Updates 682 repolist: 17,492
# yum repolist --disablerepo=epel Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * base: ftp.ines.lug.ro * elrepo: ftp.ines.lug.ro * extras: ftp.ines.lug.ro * updates: ftp.ines.lug.ro repo id repo name status base/7/x86_64 CentOS-7 - Base 8,652 elrepo ELRepo.org Community Enterprise Linux Repository - el7 143 extras/7/x86_64 CentOS-7 - Extras 128 updates/7/x86_64 CentOS-7 - Updates 682 repolist: 9,605
So what's going on with epel?
TIA, :-) Marko
On Thu, Jun 18, 2015 at 10:04:04PM +0100, Marko Vojinovic wrote:
Hi everyone,
This just came to my attention --- I have CentOS 7 installed on one machine, and have configured elrepo and epel as additional repositories. When I turned on the yum-priorities package (and set up priorities in the order base&updates < elrepo < epel), it turns out that there are 65 conflicting packages between base and epel, and additional 5 between elrepo and epel (there are no conflicts between base and elrepo, as expected).
Somehow I thought (without going to verify) that epel should be before elrepo.
Just looked at my repo configs and I have epel priority at 20 and elrepo at 40.
As far as I understand, this shouldn't happen. Does anyone know which packages are conflicting, and why?
Here is the relevant yum output, note the excluded packages info:
# yum repolist Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile
- base: ftp.ines.lug.ro
- elrepo: ftp.ines.lug.ro
- epel: mirror.pmf.kg.ac.rs
- extras: ftp.ines.lug.ro
- updates: ftp.ines.lug.ro
70 packages excluded due to repository priority protections repo id repo name status base/7/x86_64 CentOS-7 - Base 8,652 elrepo ELRepo.org Community Enterprise Linux Repository - el7 143 epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 8,025+70 extras/7/x86_64 CentOS-7 - Extras 128 updates/7/x86_64 CentOS-7 - Updates 682 repolist: 17,630
# yum repolist --disablerepo=elrepo Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile
- base: ftp.ines.lug.ro
- epel: mirror.pmf.kg.ac.rs
- extras: ftp.ines.lug.ro
- updates: ftp.ines.lug.ro
65 packages excluded due to repository priority protections repo id repo name status base/7/x86_64 CentOS-7 - Base 8,652 epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 8,030+65 extras/7/x86_64 CentOS-7 - Extras 128 updates/7/x86_64 CentOS-7 - Updates 682 repolist: 17,492
# yum repolist --disablerepo=epel Loaded plugins: fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile
- base: ftp.ines.lug.ro
- elrepo: ftp.ines.lug.ro
- extras: ftp.ines.lug.ro
- updates: ftp.ines.lug.ro
repo id repo name status base/7/x86_64 CentOS-7 - Base 8,652 elrepo ELRepo.org Community Enterprise Linux Repository - el7 143 extras/7/x86_64 CentOS-7 - Extras 128 updates/7/x86_64 CentOS-7 - Updates 682 repolist: 9,605
So what's going on with epel?
TIA, :-) Marko
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 18 Jun 2015 17:53:14 -0400 Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Thu, Jun 18, 2015 at 10:04:04PM +0100, Marko Vojinovic wrote:
Hi everyone,
This just came to my attention --- I have CentOS 7 installed on one machine, and have configured elrepo and epel as additional repositories. When I turned on the yum-priorities package (and set up priorities in the order base&updates < elrepo < epel), it turns out that there are 65 conflicting packages between base and epel, and additional 5 between elrepo and epel (there are no conflicts between base and elrepo, as expected).
Somehow I thought (without going to verify) that epel should be before elrepo.
Just looked at my repo configs and I have epel priority at 20 and elrepo at 40.
The priority between elrepo and epel is usually a matter of personal preference, but either way epel is stepping over the base and updates repos, regardless of elrepo, as I explained:
# yum repolist --disablerepo=elrepo Loaded plugins: fastestmirror, langpacks, priorities
[snip]
65 packages excluded due to repository priority protections
This shouldn't happen, and as far as I know, it is considered a Bad Thing(tm). Does anyone have any more detailed info regarding this?
Best, :-) Marko
Le 19/06/2015 05:16, Marko Vojinovic a écrit :
On Thu, 18 Jun 2015 17:53:14 -0400 Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Thu, Jun 18, 2015 at 10:04:04PM +0100, Marko Vojinovic wrote:
Hi everyone,
This just came to my attention --- I have CentOS 7 installed on one machine, and have configured elrepo and epel as additional repositories. When I turned on the yum-priorities package (and set up priorities in the order base&updates < elrepo < epel), it turns out that there are 65 conflicting packages between base and epel, and additional 5 between elrepo and epel (there are no conflicts between base and elrepo, as expected).
Somehow I thought (without going to verify) that epel should be before elrepo.
Just looked at my repo configs and I have epel priority at 20 and elrepo at 40.
The priority between elrepo and epel is usually a matter of personal preference, but either way epel is stepping over the base and updates repos, regardless of elrepo, as I explained:
# yum repolist --disablerepo=elrepo Loaded plugins: fastestmirror, langpacks, priorities
[snip]
65 packages excluded due to repository priority protections
This shouldn't happen, and as far as I know, it is considered a Bad Thing(tm). Does anyone have any more detailed info regarding this?
You are correct, but what "more info" do you want? You've spelled it out quite well, you have the solution (set the lowest prio == highest value for epel), end of story? If you want it fixed you should report this to EPEL, not here. But with a large repo like EPEL this is bound to happen again and again as the distrib is a moving target. yum priorities mostly solves it.
On Fri, Jun 19, 2015 at 12:01 AM, Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
Le 19/06/2015 05:16, Marko Vojinovic a écrit :
65 packages excluded due to repository priority protections
This shouldn't happen, and as far as I know, it is considered a Bad Thing(tm). Does anyone have any more detailed info regarding this?
If you want it fixed you should report this to EPEL, not here. But with a large repo like EPEL this is bound to happen again and again as the distrib is a moving target. yum priorities mostly solves it.
One thing people should be aware is that EPEL is built for RHEL and that the package list is not the same between RHEL and CentOS. For example, CentOS adds cloud-related ones to the centos-extras repo which may overlap EPEL's.
By the way, when I ran the same yum repolist command on my RHEL box with epel enabled, there was no conflict.
Akemi
On Fri, 19 Jun 2015 00:13:25 -0700 Akemi Yagi amyagi@gmail.com wrote:
One thing people should be aware is that EPEL is built for RHEL and that the package list is not the same between RHEL and CentOS. For example, CentOS adds cloud-related ones to the centos-extras repo which may overlap EPEL's.
Thanks for the info. How can I find out the package names for the overlap? Can yum spell them out for me somehow?
By the way, when I ran the same yum repolist command on my RHEL box with epel enabled, there was no conflict.
That's good to know. So it seems that folks in epel do take care not to create conflicts, but wrt. to RHEL, but not CentOS. Given that, I'd just like to know which packages to check for on my machine... :-)
Thanks, :-) Marko
On 06/19/2015 05:36 AM, Marko Vojinovic wrote:
On Fri, 19 Jun 2015 00:13:25 -0700 Akemi Yagi amyagi@gmail.com wrote:
One thing people should be aware is that EPEL is built for RHEL and that the package list is not the same between RHEL and CentOS. For example, CentOS adds cloud-related ones to the centos-extras repo which may overlap EPEL's.
Thanks for the info. How can I find out the package names for the overlap? Can yum spell them out for me somehow?
If you include the "-v" option in that "yum repolist" command you'll see what packages were excluded by the priorities plugin.
On Fri, 19 Jun 2015 09:01:43 +0200 Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
You are correct, but what "more info" do you want?
Well, a list of names of those conflicting packages would be nice to have. Or instructions how to ask yum to compile it.
You've spelled it out quite well, you have the solution (set the lowest prio == highest value for epel), end of story?
Unfortunately, it isn't. I was running the machine for some time without having the yum-priorities plugin. I (naively) believed that EPEL is careful not to create conflicts against base (I have read on this very list that it's safe to use). Stuff got installed, updated several times over, etc.
Now after I figured there are in fact conflicts, I need to figure out the consistency of the software installed on my machine. How many (and which) packages from base have been stepped over by epel on my system? How severe are the consequences?
I need to know how affected my system is, which packages to reinstall (now that I've activated priorities), etc. It's a mess that needs to be cleaned up.
If you want it fixed you should report this to EPEL, not here. But with a large repo like EPEL this is bound to happen again and again as the distrib is a moving target. yum priorities mostly solves it.
No, I don't really care to have it fixed, yum-priorities can take care of that in the future. But I want to fix my server, to make sure that all packages from base are still there.
And I also want to make some noise about it on this list, so that other people don't end up with the same problem. It should be stated clearly that epel is *not* safe to use without the priorities plugin.
Best, :-) Marko
On Fri, 19 Jun 2015, John Hodrien wrote:
On Fri, 19 Jun 2015, Marko Vojinovic wrote:
Well, a list of names of those conflicting packages would be nice to have. Or instructions how to ask yum to compile it.
yum update -d3
I also wonder if some of this is historical. Are you pointing at EPEL, or an internal mirror of EPEL? There are packages that used to be in EPEL7 (perhaps EPEL7-beta) that are provided in base, but are no longer provided in EPEL (e.g. golang, thunderbird, xmlsec1).
jh
On Fri, 19 Jun 2015 11:36:45 +0100 (BST) John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Fri, 19 Jun 2015, Marko Vojinovic wrote:
Well, a list of names of those conflicting packages would be nice to have. Or instructions how to ask yum to compile it.
yum update -d3
Wow! Excellent! Thanks a bunch!
Best, :-) Marko
On 06/19/2015 05:29 AM, Marko Vojinovic wrote:
On Fri, 19 Jun 2015 09:01:43 +0200 Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
You are correct, but what "more info" do you want?
Well, a list of names of those conflicting packages would be nice to have. Or instructions how to ask yum to compile it.
You've spelled it out quite well, you have the solution (set the lowest prio == highest value for epel), end of story?
Unfortunately, it isn't. I was running the machine for some time without having the yum-priorities plugin. I (naively) believed that EPEL is careful not to create conflicts against base (I have read on this very list that it's safe to use). Stuff got installed, updated several times over, etc.
Now after I figured there are in fact conflicts, I need to figure out the consistency of the software installed on my machine. How many (and which) packages from base have been stepped over by epel on my system? How severe are the consequences?
I need to know how affected my system is, which packages to reinstall (now that I've activated priorities), etc. It's a mess that needs to be cleaned up.
If you want it fixed you should report this to EPEL, not here. But with a large repo like EPEL this is bound to happen again and again as the distrib is a moving target. yum priorities mostly solves it.
No, I don't really care to have it fixed, yum-priorities can take care of that in the future. But I want to fix my server, to make sure that all packages from base are still there.
And I also want to make some noise about it on this list, so that other people don't end up with the same problem. It should be stated clearly that epel is *not* safe to use without the priorities plugin.
To be perfectly honest, the differences between EPEL and Base+extras can usually be completely ignored anyway.
While somethings may be in epel and extras .. and the extras versions might lag, the extras version likely came from EPEL in the first place and was added as a build requirement for some other package in extras.
This means that if there is a newer version in EPEL later, it is likely not going to cause a problem if it is installed on CentOS .. and in reality, we should probably be pulling that newer EPEL package into extras anyway.
I don't think, if you stay in the elrepo, EPEL, and Base+Extras family that you are going to be hurt very often using whatever yum finds without yum-priorities at all. I would add the NUX repo to those as well. If you go outside those 4, maybe yum-priorities become more important.
I am sure with 8,000 or so total packages, one might find a conflict that matters .. but I don't know of any that matter right now. By matter, I mean that there is an actual issue using the newer package from the 4 repos, whichever one that is.
On Fri, Jun 19, 2015 at 02:54:21PM -0500, Johnny Hughes wrote:
On 06/19/2015 05:29 AM, Marko Vojinovic wrote:
On Fri, 19 Jun 2015 09:01:43 +0200 Nicolas Thierry-Mieg Nicolas.Thierry-Mieg@imag.fr wrote:
You are correct, but what "more info" do you want?
Well, a list of names of those conflicting packages would be nice to have. Or instructions how to ask yum to compile it.
You've spelled it out quite well, you have the solution (set the lowest prio == highest value for epel), end of story?
Unfortunately, it isn't. I was running the machine for some time without having the yum-priorities plugin. I (naively) believed that EPEL is careful not to create conflicts against base (I have read on this very list that it's safe to use). Stuff got installed, updated several times over, etc.
Now after I figured there are in fact conflicts, I need to figure out the consistency of the software installed on my machine. How many (and which) packages from base have been stepped over by epel on my system? How severe are the consequences?
I need to know how affected my system is, which packages to reinstall (now that I've activated priorities), etc. It's a mess that needs to be cleaned up.
If you want it fixed you should report this to EPEL, not here. But with a large repo like EPEL this is bound to happen again and again as the distrib is a moving target. yum priorities mostly solves it.
No, I don't really care to have it fixed, yum-priorities can take care of that in the future. But I want to fix my server, to make sure that all packages from base are still there.
And I also want to make some noise about it on this list, so that other people don't end up with the same problem. It should be stated clearly that epel is *not* safe to use without the priorities plugin.
To be perfectly honest, the differences between EPEL and Base+extras can usually be completely ignored anyway.
While somethings may be in epel and extras .. and the extras versions might lag, the extras version likely came from EPEL in the first place and was added as a build requirement for some other package in extras.
This means that if there is a newer version in EPEL later, it is likely not going to cause a problem if it is installed on CentOS .. and in reality, we should probably be pulling that newer EPEL package into extras anyway.
I don't think, if you stay in the elrepo, EPEL, and Base+Extras family that you are going to be hurt very often using whatever yum finds without yum-priorities at all. I would add the NUX repo to those as well. If you go outside those 4, maybe yum-priorities become more important.
I used to add RPMFUSION to that, but as of last time I looked, not more than 2-3 weeks ago, they still don't have EL7 listed.
On Fri, 19 Jun 2015 14:54:21 -0500 Johnny Hughes johnny@centos.org wrote:
To be perfectly honest, the differences between EPEL and Base+extras can usually be completely ignored anyway.
While somethings may be in epel and extras .. and the extras versions might lag, the extras version likely came from EPEL in the first place and was added as a build requirement for some other package in extras.
This means that if there is a newer version in EPEL later, it is likely not going to cause a problem if it is installed on CentOS .. and in reality, we should probably be pulling that newer EPEL package into extras anyway.
I don't think, if you stay in the elrepo, EPEL, and Base+Extras family that you are going to be hurt very often using whatever yum finds without yum-priorities at all. I would add the NUX repo to those as well. If you go outside those 4, maybe yum-priorities become more important.
I am sure with 8,000 or so total packages, one might find a conflict that matters .. but I don't know of any that matter right now. By matter, I mean that there is an actual issue using the newer package from the 4 repos, whichever one that is.
Yes, I agree. After I went through the list of conflicting packages, I failed to find anything that could even remotely be called critical or dangerous. So in the end, one probably doesn't need yum-priorities if one stays within the four main repos.
Anyway, thanks for the info!
Best, :-) Marko
On 18/06/15 22:04, Marko Vojinovic wrote:
Hi everyone,
This just came to my attention --- I have CentOS 7 installed on one machine, and have configured elrepo and epel as additional repositories. When I turned on the yum-priorities package (and set up priorities in the order base&updates < elrepo < epel), it turns out that there are 65 conflicting packages between base and epel, and additional 5 between elrepo and epel (there are no conflicts between base and elrepo, as expected).
The overlap between elrepo and EPEL is due to the 5 VirtualGL packages in elrepo.
VirtualGL packages, albeit 64-bit only, are also available in EPEL. They don't appear to be shipping the 32-bit VirtualGL libs.
On Fri, 19 Jun 2015 07:51:36 +0100 Ned Slider ned@unixmail.co.uk wrote:
The overlap between elrepo and EPEL is due to the 5 VirtualGL packages in elrepo.
VirtualGL packages, albeit 64-bit only, are also available in EPEL. They don't appear to be shipping the 32-bit VirtualGL libs.
Exactly what I wanted to hear, thanks a lot! :-)
Just checked, I have the elrepo version installed (and now that I've configured yum-priorities, it'll stick unless I decide I need the epel version).
Thanks, :-) Marko