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, agreed! > - 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 > spot on! > 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. > absolutely! > > > 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. > >