Package install is never up to date

Expected Behavior

Kitchen converge on subsequent runs should have no resources changed

Current Behavior

On subsequent runs the package for sensu keeps getting installed, as a result it triggers a service restart.

Possible Solution

Basically the issue appears to be in the epoch version. if I do a yum info of sensu I get
Name : sensu Arch : x86_64 Epoch : 1 Version : 1.5.0 Release : 1.el7 Size : 82 M Repo : installed From repo : sensu Summary : A monitoring framework that aims to be simple, malleable, and scalable. URL : https://sensu.io License : MIT Description : A monitoring framework that aims to be simple, malleable, and scalable.

and if I in my cookbook a simple
package 'sensu' do version '1:1.5.0-1.el7' end
Everything works as expected. But using the attribute
default["sensu"]["version"] = '1:1.5.0-1'
I get an error
FATAL: ArgumentError: Malformed version number string 1:1.5.0
if I use
default["sensu"]["version"] = '1.5.0-1'
The package just gets installed at every run of chef and triggers a restart of the service
Looks like were doing a lazy against the helper to join the version together in the helper. so I wonder if there is either an issue in sending the ':' to the helper, which seems fine and just does a join anyway or something else?

Steps to Reproduce (for bugs)

1. kitchen converge with a wrapper on centos 7
2. set your version attribute to '1.5.0-1.'
   3.kitchen converge first time things look good
   4.kitchen converge a second time and package is set to install again, triggering a restart of he service

Context

Right now im trying to get he cookbook working before putting this up into the environment

Your Environment

• Version of this cookbook used: 'sensu', '= 5.4.0'
• Version of Sensu used: 1.5.0-1
• Version of Chef used: 14.5.33
• Operating System and version (e.g. CentOS 7, Ubuntu 14.04): Centos 7

[majormoses]

Hmm I don't recall seeing this with ubuntu I think you need to configure both of these attributes because epel versioning as of centos7: https://github.com/sensu/sensu-chef/blob/v5.4.0/attributes/default.rb#L20-L21 Let me know if that works if not I can try to dig into it a bit.

Hmm I don't recall seeing this with ubuntu I think you need to configure both of these attributes because epel versioning as of centos7: https://github.com/sensu/sensu-chef/blob/v5.4.0/attributes/default.rb#L20-L21 Let me know if that works if not I can try to dig into it a bit.

Thanks for the reply. This is actually to do with the epoch value not the platform value.
default["sensu"]["version_suffix"] looks like el7 is whats getting tagged as in
suffix = suffix_override || ".el#{platform_major}"

what I'm needing or at least running into is its wanting the affix which is what epoch is. At least thats what I can see.

[majormoses]

I will try to look into this sometime this week but I am on-call so I can't guarantee I will find much time until the weekend. Can you verify if the debian based distros also exhibit this issue?

Apologies got a little busy with some things at work. Yes I will most likely have some time in the morning to delve a little into this. On a side note speaking of denian looks like this has been addressed to #517
Then looking at the code for how a debian package is installed it does a simple
package "sensu" do version node["sensu"]["version"] options package_options notifies :create, "ruby_block[sensu_service_trigger]" end

Which actually supports what I noticed when adding epoch.
Where redhat a helper library gets called which isnt to crazy but with the lazy enumeration I think thats where having a colon gets messed up.

I will need to test tho if not including epoch will suffice a package already being up to date in debian.

[majormoses]

@xxwassyxx just checking if you had time to get around to this