Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
yum_package version property needs to be stricter about requiring the epoch #8883
yum_package don't keep idempotency if set version on Chef 15
Chef Client 15.3.14
yum_package 'java-11-openjdk' do version '220.127.116.11-0.el7_6' end
You need to include the epoch:
alternatively it works when including the version in the name:
using the version in the name with yum_package is encouraged over using the version as the property, particularly around handling epochs.
Although it looks like there's some kind of wonky bug here since with that last line it looks like we've correctly done a versioncompare against the installed and available versions of the package and determined equality and its not at all clear why it then goes and decides to install the package (which is an "install" not and "upgrade" so why if we have anything that satsifies the "whatinstalled" check are we doing anything?
I'm guessing something went wrong with patching the superclass.
yeah when it works we get a match:
something is up with that versioncompare, not even sure what that is necessary when we're doing
Ah I see.
When you specify it in the name with no version check then chef does not do any management of the version since it doesn't parse the version out of the name, that's just a label shipped to the underlying python, so there's no need to check the version.
When you specify the version in the version property you are telling chef what version to install. The version comparison against the installed package is correct, it does not match since the epoch does not match. We can't actually hack that up to do fuzzy matching.
We may need to make the version property stricter to always match epochs, and then provide better error messaging around the version property to force people to match epochs if the available package requires an epoch (although literally trying to do that will probably produce awful code, so we need a solution a bit more elegant than the design in my head right now).
TL;DR: This is more improper use of Chef than bugginess in Chef. Users need to include epochs in version if the package has an epoch. Chef should probably be stricter about enforcing the use of epochs and should probably error out rather than installing packages that have non-zero epochs. When it errors out it should give a more useful error message that the user may have omitted an epoch and steer them better towards including an epoch in the version. The need to include the epoch in the version is not itself a bug, that is the correct fix for users.