On Thu, Oct 23, 2014 at 2:44 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Thu, Oct 23, 2014 at 7:02 AM, Jim Perrin jperrin@centos.org wrote:
It does indeed. This circles back to a discussion several months ago on this list about tiered repositories, best practices, etc. We've known for a while that this would come up, but before it was mostly just discussion and theory. Now we're looking at putting it into practice with deliverable content.
So was/is there a theoretical resolution of how to handle tiered/alternative packages either where concurrent installations conflict or where concurrent installations are desirable along with a way to distinguish which instance you want to run. In this context, I'm not sure it is even relevant whether or not these packages come from different repositories.
The only completely reliable way to do this is user-tuning of exclusions in the local configurations. As long as you have only a few well built repositories that are careful not to overlap the core, such as EPEL and RPMfusion enabled, or a well defined target repository such as I publish hooks for Samba 4, you're OK. But as soon as you start updating a lot of Perl modules to resolve Perl dependency hell, for example to update something like RT 4 or MusicBrainz, or to introduce overlapping 3rd party repositories like JPackage, well, you're in for adventures. It's no longer plug and play, and you have to be ready to set exclusions in other repository configurations or make plugins to provide compatibility.
Particular examples for particular packages include jpackage-utils from JPackage, and the rather incompatible layouts of nagios-plugins from Repoforge and from EPEL. Managing that sort of thing can get very complex very quickly if you want unlimited access to all such repos, and don't want to allow your setups for one to touch your setups for the other.
Nico Kadel-Garcia