adding add-yum_repository-to-core.md

[someara]

No description provided.

[lamont-granquist]

Biggest concern that I've got is the windows_package core-chef vs. windows_package cookbook issue rearing its head again. Since you've got the same names, they'll collide, and you want to make sure that the cookbook either drops the resource entirely, or for back-compat it will only load the resource in the cookbook if the core chef resource does not exist. Someone who has upgraded their chef version but hasn't upgraded their cookbook version would still wind up with conflicts, but I think that's unavoidable.

[jtimberman]

I'm 👍 on adding a yum repository provider to core Chef.

As an implementation example for comparison, see the homebrew cookbook 🍨.

[jonlives]

👍

[martinisoft]

👍

[danielsdeleo]

👍 though I would prefer this be expanded to include apt as well. Seems like it would be super weird if you need the apt cookbook to install an apt repo but you get yum out of the box.

[thommay]

👍 with the assumption that others will follow into core

[jonlives]

Per @adamhjk's delegation of deciderating component-specific resources into core, I hereby approve this message.

[jonlives]

Closing this off as resource submissions into core don't need an RFC - @someara, I shall await your PR with great interest :p

[miketheman]

@someara some notes about testing for your future pr:

• new resource is in core and current cookbooks use interfaces from the current cookbook?
• new resource is in core, cookbook is in run list, what behavior is seen and used?

https://www.chef.io/blog/2015/02/10/chef-12-provider-resolver/ might be interesting

Basically, using a cookbook with the same resource name should override the code resource.

[jaym]

@someara some info about the windows cookbook:
The reason we were forced to create a library file for the windows_package resource/provider in the windows cookbook is because Chef 12 no longer overrides already defined constants. See chef/chef@02fb966?diff=split#diff-899b2263bd317e2bded0e852483b1a11R92

The way around this in Chef 12 is to use a name that does not conflict with a constant that would already be defined, in this case the conflicting names being Chef::Resource::WindowsPackage and Chef::Provider::WindowsPackage. After doing this, we can use the provides dsl method. Since we want to choose the name of the constants, we can not use the lwrp dsl.