[CentOS-devel] Shipping an EPEL release

On 09/16/2012 09:05 PM, Ned Slider wrote:
> On 16/09/12 17:19, Les Mikesell wrote:
>> On Sat, Sep 15, 2012 at 1:01 PM, Ned Slider<ned at unixmail.co.uk>   wrote:
>>> On 15/09/12 17:04, Les Mikesell wrote:
>>>> I disagree.  I'd much rather see commonly needed 3rd party repos
>>>> included but with enabled=0. settings.
>>>
>>> But that's not your decision to make - it's a decision for the repo
>>> themselves how they configure their repo in their config file.
>> If it is included, it can be patched.   Debian/ubuntu do this somewhat
>> sensibly but there you have to make a one-time selection to enable the
>> extra repos.  I think it is nicer to keep the alternative ones (except
>> maybe EPEL) disabled.
>>
> As a repo provider, if you patch it you can support it as it's no longer
> what I ship. I don't want the extra support load when you break what I ship.
>
> Which is pretty much the same response you'll hear from CentOS every
> time someone posts with a system running a non-CentOS kernel.
>
> IMHO that's not what CentOS wants here. It's certainly not what 3rd
> party repo providers would want either.
>
Which is why in my opinion the better option is to
- include the release rpm exactly as shipped by the 3rd party repo,
- in centos-extras, so that a) it is [ more or less] obvious [ for those 
who bother to read about the CentOS repositories] that it is supplied 
for user convenience but not part of CentOS and b) it cannot get 
installed by default unless the user|admin explicitly asks for it to be 
installed

Bonus points for updating it in the CentOS mirrors when the 3rd party 
repo admins decide to update it, but this is not mandatory as the first 
update after install will update the release.rpm, too , if needed.



For those who are afraid about the conflicts/overrides between EPEL and 
[base]: those conflicts/overrides normally appear ONLY for packages 
which are NOT distributed as part of main RHEL but in additional 
channels which require separate subscriptions. Those who use the special 
channels are well experienced and I am 100% sure that they would not cry 
for help in the CentOS support channels. And in the rare cases when 
conflicts do occur ( mainly when RHEL releases new minor versions and 
their package maintainers do not bother to sync with EPEL maintainers ), 
EPEL does its best to take all the needed steps to solve the conflicts. 
i.e. it usually removes the offending packages. So please, let's not 
throw away the baby together with the dirty water.