[CentOS-devel] Policy for Ad-Hoc Upstreams: Development Hosting

On Thu, Oct 23, 2014 at 2:44 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> On Thu, Oct 23, 2014 at 7:02 AM, Jim Perrin <jperrin at 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