> Am Mittwoch, den 03.02.2010, 14:04 +0100 schrieb Nico Kadel-Garcia: >> Would it be possible to put copies of the subversion.i386 and >> subversion-devel.i386 packages in the x86_64 repositories? The issue >> is that, with "yum", if you say "yum install subversion" on RHEL 4 and >> 5, it detects the built-in RHEL version of the ancient 1.4.2 , i386 >> version of these packages and tries to install them in parallel with >> the new, RPMforge publiched 1.6.6 x86_64 versions. And this way lies >> cleanup madness. >> >> Installing the i386 and x86_64 versions together seems to work fine, >> as it does for RHEL packages. > > IMHO you should exclude packages from the base repos if you want to > override them from 3rd party repos. That way it also works correct with > protectbase or priorities plugin. > > Chris
Chris, that can get *really* nasty. The problem is partly that for registered RHEL clients, they use what is basically up2date in grandma's clothing as part of the yum-rhn-plugin utility that downloads RPM's from RedHat Network. This has no Yum .repo file: you wind up having to edit yum.conf and exclude the alternative versions of the packages *entirely*, but only on the x86_64 platforms. That means you can't use the same yum.conf on i386 and x86_64, and it can become awkward to support. I'm convinced that graceful 3rdparty repositories like RPMforge should avoid having to tweak *other* system files to operate correctly, especially when the solution is simply to follow RHEL's example and make the i386 package available in the x86_64 repository. For environments like JPackage, where the new package's format is .noarch instead of .i386 or .x86_64, blocking them in yum is more necessary. But here, the solution from the repository side is easier for most users. I've been running it this last week on an RHEL 5 box, and having them both installed is harmless. "rpm -V" does report some discrepancies in checksums of some of the documentation files (due to the slightly separate compilation processes, I think), and altered timestamps on other documentation files. But I see no other issues with it. _______________________________________________ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest