[chef] Re: Re: Re: Re: Re: Re: Depending on yum '< 3'

[Jorge Bianquetti < >]

knife cookbook site show  still shows affected versions.

Thanks!

2013/12/12 Sean OMeara 
<
 >:
> Sorry about that hitch.... I updated everything to include '< 3.0' to
> satisfy the x.y format
>
>
> On Thu, Dec 12, 2013 at 3:45 AM, Jorge Bianquetti 
> <
 >
> wrote:
>>
>> I get this error when I try to use any of the cookbooks updated to
>> include:
>>
>> depends 'yum', '<3'
>>
>>        [2013-12-12T08:40:37+00:00] ERROR: '3' does not match 'x.y.z' or
>> 'x.y'
>>
>> If I change this lines to:
>>
>> depends 'yum', '<3.0'
>>
>> cookbook works without issues
>>
>> I'm using Chef 11.8.2-1.ubuntu.12.04, installed from Omnibus.
>>
>> Nobody have same issue?
>>
>>
>> 2013/12/9 Sean OMeara 
>> <
 >:
>> > Hi Mike.
>> >
>> > Indeed, yum is a fundamental building block. That is why it's important
>> > to
>> > be as solid as possible. The rewrite is part of COOKs focus on well
>> > engineered primitives.
>> >
>> > We also need some easy-to-point-to "example cookbooks" we can point to
>> > and
>> > say "write your cookbook like that". In general, people tend to copy
>> > patterns they see, especially newcomers.
>> >
>> > I've added aliases for :create :add :remove, and :delete, as well as
>> > baseurl/url and gpgkey/keyurl. That should help smooth the transition.
>> >
>> > If you can help me test this, it would be amazing.
>> > Thanks!
>> >
>> > -s
>> >
>> >
>> > On Sat, Dec 7, 2013 at 9:48 AM, Mike 
>> > <
 >
>> >  wrote:
>> >>
>> >> Sean,
>> >>
>> >> From an initial test, the most naive one I've got, is this:
>> >>
>> >> Berksfile:
>> >> cookbook 'yum', github: 'opscode-cookbooks/yum', branch: 'tableflip' #
>> >> Test out yum 3.x branch
>> >>
>> >> Cookbook:
>> >>   yum_repository "datadog" do
>> >>     name "datadog"
>> >>     description "datadog"
>> >>     url "http://yum.datadoghq.com/rpm";
>> >>     action :add
>> >>   end
>> >>
>> >> Fails due to the 'url' resource param being missing, apparently this
>> >> has
>> >> been renamed to 'baseurl', and the action :add is gone, is now :create.
>> >>
>> >> - Is there a way to create aliases for LWRP parameters, so that we
>> >> could
>> >> possibly have an `alias :baseurl :url`, `alias :action_add
>> >> :action_create`
>> >> and such, so we could maintain some more backwards compatibility?
>> >>
>> >> Parameter aliasing is used in some base resources:
>> >> Ref:
>> >>
>> >> https://github.com/opscode/chef/blob/master/lib/chef/resource/git.rb#L40-L43
>> >>
>> >>
>> >> https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/resource/git.rb#L40-L43
>> >>
>> >> Here's an example of aliasing in a provider, where `action_create` is
>> >> now
>> >> also `action_run` for the ruby_block resource:
>> >>
>> >>
>> >> https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/provider/ruby_block.rb#L31
>> >>
>> >>
>> >> https://github.com/opscode/chef/blob/master/lib/chef/provider/ruby_block.rb#L38
>> >>
>> >> I don't know if LWRPs will provide the same amount of functionality,
>> >> someone more deep inside LWRPs should probably answer that.
>> >>
>> >> At least for one more Major version, with deprecation warnings, if at
>> >> all
>> >> possible.
>> >>
>> >> - It appears gpgcheck default switched from false to true - any reason
>> >> to
>> >> not keep that false, and have the conditional swap based on providing a
>> >> gpgkey param? This was the previous behavior, as if I don't pass a
>> >> gpgkey
>> >> explicitly, I'd get the default of no gpgcheck.
>> >>
>> >> In general this looks pretty awesome, includes a bunch of new tests,
>> >> code
>> >> quality, what have you.
>> >>
>> >> My biggest question is:
>> >>
>> >> - Considering that the driving factor for most cookbook changes is
>> >> handled
>> >> within the context of a Ticket, which is then reviewed, discussed, etc
>> >> - is
>> >> there one associated with this change, that discusses the motivation,
>> >> the
>> >> need, etc?
>> >>
>> >> The reason I'm delving deep into this one is because it's a fundamental
>> >> building block for anyone using/deploying software, and has a lot of
>> >> potential for unexpected Bad Stuff, and getting my cookbook updated to
>> >> constrain on a prior version of this cookbook, and then getting that
>> >> change
>> >> out to every user of my cookbook might be a little time-constrained
>> >>
>> >> Thanks for playing,
>> >> -Mike
>> >>
>> >> PS: I'd note that the current branch's repo still uses version string
>> >> 2.4.3 - Another use case for Semantic Versioning identifiers to allow
>> >> this
>> >> to be 3.0.0.dev or such, but that's already a whole other bag of
>> >> marbles.
>> >>
>> >>
>> >> On Sat, Dec 7, 2013 at 8:27 AM, Mike 
>> >> <
 >
>> >>  wrote:
>> >>>
>> >>> Looks like the branch is here:
>> >>> https://github.com/opscode-cookbooks/yum/tree/tableflip
>> >>>
>> >>>
>> >>> On Sat, Dec 7, 2013 at 8:07 AM, Wolfe, Eric G
>> >>> <
 >
>> >>> wrote:
>> >>>>
>> >>>> Got a branch we can review before the release?
>> >>>>
>> >>>> Sean OMeara 
>> >>>> <
 >
>> >>>>  wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>> Dear Chef People:
>> >>>>
>> >>>> In one week, I will be releasing a new yum cookbook to the community
>> >>>> site that will Break All The Things. If you depend on yum, please
>> >>>> lock to '<
>> >>>> 3' in your metadata.rb to avoid trouble.
>> >>>>
>> >>>> Thanks.
>> >>>> -s
>> >>>> —
>> >>>> Sent from Mailbox<https://www.dropbox.com/mailbox> for iPhone
>> >>>
>> >>>
>> >>
>> >
>
>