On Fri, 19 Jun 2015 09:01:43 +0200 Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at 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, 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 jh
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 -d3I 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 at 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 -d3Wow! 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 at 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20150619/fc997b5c/attachment-0001.sig>
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 at 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. -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- Show me your ways, O LORD, teach me your paths; Guide me in your truth and teach me, for you are God my Savior, And my hope is in you all day long. -------------------------- Psalm 25:4-5 (NIV) --------------------------------
On Fri, 19 Jun 2015 14:54:21 -0500 Johnny Hughes <johnny at 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