[CentOS-devel] Shipping an EPEL release
wolfy at nobugconsulting.ro
Sun Sep 16 14:26:45 EDT 2012
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