Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   CentOS (http://www.linux-archive.org/centos/)
-   -   Third party repo differences (was: Repositories in CentOS 5.8) (http://www.linux-archive.org/centos/670659-third-party-repo-differences-repositories-centos-5-8-a.html)

Lamar Owen 05-24-2012 07:09 PM

Third party repo differences (was: Repositories in CentOS 5.8)
 
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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Lamar Owen 05-25-2012 12:00 AM

Third party repo differences (was: Repositories in CentOS 5.8)
 
On Thursday, May 24, 2012 03:26:02 PM Les Mikesell wrote:
> But many, probably most of those cases are revs with forward/backward
> compatibility. It's hard to generalize about that, though.

Yep, it sure is. Forward/backward compatibility is almost entirely in the hands of the upstream projects (upstream from Red Hat). Some do that kindof thing well; others do not. Open source not only gives choice to the user, but also transfers the responsibility for choosing wisely to the user making the choice.

> Even in
> the scalpel case you mentioned the up-rev lib was likely compatible
> but just specified as requiring an exact version in the spec file.

The one that has bitten me the hardest is xrdp. It will bite harder once a release based on FreeRDP rather than rdesktop is released out of git. The compatibility depends entirely on the package's upstream policies, developers, and stage of development (xrdp isn't out of beta, after all).

> And on the other side there are things like viewvc that are at the
> same rev in epel and rpmforge but have slightly different and
> incompatible configurations (and there is a reason I know that...).

Likewise amavisd-new. It's not rare to have issues, and lots of people have had them, thus my cautions. Not trying to scare anyone off from any third party repository; just want to give information that allows people to make informed decisions, and show people how I at least arrived at my conclusions that work for me with my particular setup; what my particular setup is isn't the important thing, it's how and why I got there that I consider potentially useful to others.

At the moment both EPEL and RPMforge are on a 2.6.x amavisd-new; 2.7 makes some changes in the AM.PDP protocol that can break, for instance, amavisd-milter (distinct from the much less useful amavis-milter). Neither repo has amavisd-milter, so that compatibility issue may not show up except to those who actually use amavisd-milter instead of the much less useful amavis-milter.

I'll step out on a limb here and generalize somewhat; I would think that most CentOS users use at least one third-party repository, if the traffic on this list is any indication (and, again, I reserve the right to be wrong). So knowing how to properly determine how to use those repos (which was the OP's question, after all) is very useful indeed, IMO.

And, again, FWIW, HTH, IMHO, YMMV, etc.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Lamar Owen 05-26-2012 04:33 PM

Third party repo differences (was: Repositories in CentOS 5.8)
 
On Saturday, May 26, 2012 05:15:41 AM David Hrbáč wrote:
> Dne 25.5.2012 02:00, Lamar Owen napsal(a):
> > At the moment both EPEL and RPMforge are on a 2.6.x amavisd-new; 2.7 makes some changes in the AM.PDP protocol that can break, for instance, amavisd-milter (distinct from the much less useful amavis-milter). Neither repo has amavisd-milter, so that compatibility issue may not show up except to those who actually use amavisd-milter instead of the much less useful amavis-milter.
>
> Lamar,
> Repoforge/RPMforge does provide amavisd-new-milter package...
> DH

David,

I understand that you are one of the RPMforge/repoforge packagers, and I thank you for your efforts.

The amavisd-new-milter package does exist for CentOS 5.8; I cannot, however, find an amavisd-new-milter package for CentOS 6 in either rpmforge or rpmforge-extras.

Which is just as well, since this amavisd-new-milter is different from amavisd-milter, which is currently at version 1.5.0, the version that is compatible with amavisd-new 2.7.0 and up. It's somewhat unfortunate to have two very different things packaged with very similar names; the amavis-milter that comes with amavisd-new is much less useful than the separate amavisd-milter ( http://amavisd-milter.sourceforge.net/ ; the one packaged with amavisd-new is the one with a README at http://www.ijs.si/software/amavisd/README.milter.txt that points to the Petr Rehor rewrite at amavisd-milter.sourceforge.net).

To my knowledge no repos have the amavisd-milter package available; I've built my own for six years or so. I've used both, and the amavisd-new-milter (/usr/sbin/amavis-milter) is not nearly as useful as this amavisd-milter. In fact, for at least the last three years I've not been able to get the amavis-milter that comes with amavisd-new to work at all, whereas amavisd-milter (the Petr Rehor version at sourceforge) works very well at version 1.5.0.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Lamar Owen 05-26-2012 07:08 PM

Third party repo differences (was: Repositories in CentOS 5.8)
 
On Saturday, May 26, 2012 12:47:04 PM Les Mikesell wrote:
> Have you looked at MimeDefang's ability to run all of your scanners
> out of one milter?

Yes.

Doing the same thing with amavisd-new on the few sendmail installs I still have running; amavisd-new runs clam (or, at one site, the sophos scanner) and spamassassin, and amavisd-milter does everything needed with one milter. Using essentially the same setup with a couple of postfix sites, but no milter in that case.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Lamar Owen 05-29-2012 07:13 PM

Third party repo differences (was: Repositories in CentOS 5.8)
 
On Monday, May 28, 2012 02:22:32 AM David Hrbáč wrote:
> Dne 26.5.2012 18:33, Lamar Owen napsal(a):
> > Which is just as well, since this amavisd-new-milter is different from amavisd-milter, which is currently at version 1.5.0, the version that is compatible with amavisd-new 2.7.0 and up. It's somewhat unfortunate to have two very different things packaged with very similar names; the amavis-milter that comes with amavisd-new is much less useful than the separate amavisd-milter ( http://amavisd-milter.sourceforge.net/ ; the one packaged with amavisd-new is the one with a README at http://www.ijs.si/software/amavisd/README.milter.txt that points to the Petr Rehor rewrite at amavisd-milter.sourceforge.net).

> I did not know about this. Are you willing to share your amavis-milter
> spec file so we can include it in Repoforge?

It's pretty basic, really. I'll dig it up; it's been a long time since I've done anything with it.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


All times are GMT. The time now is 02:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.