[CentOS-devel] Shipping an EPEL release
ned at unixmail.co.uk
Sun Sep 16 19:08:21 UTC 2012
On 16/09/12 19:26, Manuel Wolfshant wrote:
> 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
> 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.
More information about the CentOS-devel