Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The resource `dpkg_package` doesn't allow downgrades #7713
This bug is similar to #6095, except that it involves
The problem is related to Chef, not to the packaging tools, since it's Chef who decides whether the package tool should be run or not. This is an example:
I can't test on RPM, so I don't have hands-on experience on
It seems it didn't:
# chef-client --version Chef: 14.6.47 # aptitude show libmysqlclient-dev | ag 'Version|State' # not held Version: 5.7.24-0ubuntu0.18.04.1 State: installed # chef-client [...] * remote_file[/var/chef/cache/libmysqlclient-dev_5.5.61-0ubuntu0.14.04.1_amd64.deb] action create_if_missing - create new file /var/chef/cache/libmysqlclient-dev_5.5.61-0ubuntu0.14.04.1_amd64.deb - update content in file /var/chef/cache/libmysqlclient-dev_5.5.61-0ubuntu0.14.04.1_amd64.deb from none to b057db (new content is binary, diff output suppressed) * dpkg_package[libmysqlclient-dev_5.5.61-0ubuntu0.14.04.1_amd64.deb] action install (up to date)
Are you explicitly pinning? Because
Interesting case! So, in short: thanks, that does the job.
The interesting part is that I've just found two oddities of the
dpkg_package package_name do source local_filename version "pizza" end
$ aptitude show libmysqlclient-dev | egrep 'State|Version' Version: 5.7.24-0ubuntu0.18.04.1 State: installed $ chef-client # [...] * dpkg_package[libmysqlclient-dev] action install - install version pizza of package libmysqlclient-dev
$ aptitude show libmysqlclient-dev | egrep 'State|Version' Version: 5.7.24-0ubuntu0.18.04.1 # look the line below; 5.5 is installed State: installed (5.5.61-0ubuntu0.14.04.1), upgrade available (5.7.24-0ubuntu0.18.04.1) $ chef-client # [...] * dpkg_package[libmysqlclient-dev] action install - install version 5.5.61-0ubuntu0.14.04.1 of package libmysqlclient-dev
I've checked the help of the
I'm not sure if version is entirely on topic with this issue, so please let me know if I need to open a separate issue (or not!).
i think that is mostly correct behavior. you want version "pizza" and "5.5.61-0ubuntu0.14.04.1" does not equal "pizza" so it fails your idempotency check, and then takes the action. the fact that the local dpkg doesn't install "pizza" but installs "5.7.24-0ubuntu0.18.04.1" is a much higher level bug. we do not check that after the action is taken that the idempotency check passes. that would be... a lot of wiring to address. also there's no validation on the version string because that always has edge conditions that fail, which prevent people from getting work done and descend into endless whack-a-mole. generally those version strings wind up being passed to commands like "yum install" so we rely on the underlying operating system throwing an error. this is an edge condition where chef is the only consumer of that version string.
so we could fix this but it would introduce a new concept into chef of validating the idempotency action in the resource after every call or something like that, and i don't think this use case is worth it. the fact that the resource is never convergent is enough to tell the user that they need to fix their version string. the other obvious thing is to drop the version string entirely. the dpkg package itself fully specifies the desired state, and using