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

Les Mikesell

lesmikesell at gmail.com
Fri Oct 24 12:40:29 UTC 2014


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



More information about the CentOS-devel mailing list