On Fri, Oct 24, 2014 at 7:20 AM, Nico Kadel-Garcia <nkadel at 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. -- Les Mikesell lesmikesell at gmail.com