On Fri, Oct 24, 2014 at 7:20 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
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.
Yes, that may be the best you can do now, but it is mostly a matter of luck since it relies on unknown future changes in likely unrelated repositories. A real solution would work even with all the packages in the same repository where the packaged could be maintained to always work.