[CentOS-devel] Overlap between EPEL and CentOS ( non upstream pkgs )

On 07/19/2014 03:26 PM, Fred Smith wrote:
> On Sat, Jul 19, 2014 at 12:46:25PM +0200, Ljubomir Ljubojevic wrote:
>> On 07/09/2014 07:04 PM, Les Mikesell wrote:
>>> On Wed, Jul 9, 2014 at 11:41 AM, Sven Kieske <svenkieske at gmail.com> wrote:
>>>>>
>>>>> Technically, this is a centos.org issue since EPEL's mandate
>>>>> requires them to not overlap with RHEL[1]. But with stuff going
>>>>> into CentOS-Extras/ and more content coming onboard from SIG's -
>>>>> and even from Core SIG - how are we going to address the overlap /
>>>>> flapping potential with EPEL ?
>>>>
>>>> I honestly think each sig should sort their issues out themselves.
>>>> reasoning with example:
>>>
>>> How do you suggest handling the likely scenario where a SIG adds a new
>>> package not currently in EPEL and subsequently EPEL adds that same
>>> package but with different contents/options/versions?
>>>
>>> Or a package in EPEL that a SIG user needs or may add includes the
>>> same file as a SIG package, creating a conflict?  Again, this may
>>> change after releases and block updates when there is no coordination
>>> among the repositories.
>>>
>>> These have been common issues, pretty much forever for people using
>>> packages from multiple repositories.   I'm not convinced there is a
>>> generic solution that doesn't involve tracking all of the files and
>>> dependencies across all of the repositories just like you have to
>>> within a single one.
>>>
>>
>>
>> I have already suggested entire yum-plugin-priorities structure in this
>> thread:
>> http://lists.centos.org/pipermail/centos-devel/2014-January/009372.html
>>
>> and here:
>> http://lists.centos.org/pipermail/centos-devel/2014-January/009520.html
>>
>> And I created/explained repository hierarchy here:
>> http://lists.centos.org/pipermail/centos-devel/2014-January/009595.html
>>
>> I am willing to further explain/expand on what I propose, so it is
>> understood as best as possible.
> 
> I've always thought, too, that priorities should be set up by default,
> and the defaults should be to protect the Centos* repos. I always set
> it up myself, giving centos* repos the lowest numbers and working up
> from there in the order of which things I don't want overwritten by
> other repos of lower priority. I usually give the Centos* repos a priority
> of ten, epel 20, and so forth, on the theory that in the *normal* case,
> I dont' want 3rd-party repos overriding the distro's own repos. I realize
> there are some cases where that isn't true, though.
> 
> I see your suggested priorities put epel and some others before the
> distro's own repos. I guess you have a good reason for that...
> 
> Fred
> 

I would, for starters, change default priority for repo without priority
set to for example 50.

Maybe even get RHEL to change that. repo configs that do not use
priorities will not be affected, and those who do already have set all
repos with priorities and they also will not be affected.

Then you set CentOS base and updates repos to 30 so every noncomplying
repo has lower priority then main repositories, and then SiG's and 3rd
party repos can introduce changes and set priority, probably even create
consensus with them to gradate all 3rd party repos in common agreement
of all 3ed party developers.

yum-plugin-priorities can be dependancy of epel-release, or centOS
-Extras release, or SiG releases, so that default core distro without
3rd party repos does not have to be affected.

-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant