On Thursday, May 24, 2012 12:42:59 PM Les Mikesell wrote: > But odds are pretty good that you could grab the scalpel src rpm from > epel and fix it to rebuild against the newer libtre in a matter of > minutes. - just changing the spec, not the source... Probably so, and I know how to do that, but I wasn't illustrating a specific workaround, just illustrating the problem. Technically, once you rebuild a package yourself you have become yet another third party repository, even if it isn't yummable, and you'll still have to pin the locally built and installed version to prevent the other repo from updating that package. I have several locally rebuilt packages on that same system for other purposes, but that wasn't what I was illustrating. > Stuff like that > does happen, but it's rare (what, one conflict out of thousands of > packages?) It's only rare if you don't hit it. After writing that sentence, I started wondering just how rare it might be, and could I throw a few lines of shell together to find out how rare it might or might not be. So I dug a little deeper. And it makes a really good exercise while taking a lunch break, so I decided to try to find out. Since yum-utils does contain the interesting repodiff utility, I ran it, with interesting and voluminous results. I took the output of repodiff ran against the baseurls of EPEL and RPMforge (using the -a to specify arches instead of taking the default of running against source packages), pulled out the list of updated packages, removed the version, release, and tags with a combination of cut, sed, and a few manual edits, and ran repoquery against both EPEL and RPMforge for the list (948 packages where the name is the same but the EVR was different), cut the resulting lists at the colon epoch separator, dropped the release, arch, dist, and repo tags from the versions, and compared the two lists of version numbers alone. Now, this is a snapshot in time, that is, the time I ran the repodiff and the repoquery commands, and things can change, and mirrors do change over time, especially with large repositories like these two. And I didn't run this on a CentOS 5.8 box, but an upstream EL6 box, so time for a subject line change. I have CentOS 6 boxes here, but none of them have both EPEL and RPMforge enabled, but my upstream EL6 box does. I found, first of all, two packages that RPMforge has in both a i386/i686 and a .noarch form: facter and perl-AnyEvent; in both cases EPEL had but one package. So I dropped the oldest version of those two in RPMforge so that I could do a straight version-to-version comparison. A simple side-by-side diff of just the version numbers produced 418 differences (424 lines of diff, twelve of which were marked with < and > instead of |, so I subtracted half of those). Manually reading through the diff, I found one difference where the version in one repo was 1.66.001 and in the other it was 1.66001, dropping a period, so that makes 417 packages where the name is the same, but the version is different. Some differences were small, some not so small. Some differences are such that the epoch was different; I didn't do a count on those, since that's not an upstream version difference, but a packaging version difference. I found that when I was looking for why the EPEL list had two fewer lines than the RPMforge list. The bottom line: out of the about 6,000 packages in EPEL, there are 7% or so that have the same name but a different version in RPMforge; out of the about 4,400 (4,381 listed by yum repolist) package in RPMforge, there are 9.5% or so that have the same name but a different version in EPEL. If anything you are running relies on any of those 417 packages, you have a potential for problems. So, it's not rare. And while I could share those lists, they will be out of date by tonight, and most certainly by when you might need or want them. Since there was a manual edit portion involved due to repodiff not outputting the epoch and its perfectly placed colon separator, it isn't very scriptable at this level. I'm sure repodiff could be modified to use the actual version numbers and names stored in the yum and rpm databases and ignoring the epoch, release, arch, dist, and repo tags. Of course, EPEL doesn't have a repo tag, so you have to remember that, too. Then you'd have another tool to help you deal with repo collisions. Perhaps such a tool has been written; I don't know about it. The repodiff tool as it stands is made for other purposes than this, and has to be shoehorned in to do this sort of comparison. Again, YMMV, FWIW, HTH, and all that. And I of course as always reserve the right to be wrong.