Affects Version/s: PUP 6.8.0
Fix Version/s: PUP 6.8.1
Template:PUP Bug Template customfield_10700 322106
Method Found:Needs Assessment
Release Notes:Bug Fix
Release Notes Summary:Removed the feature for virtual package support for dpkg provider.
QA Risk Assessment:Needs Assessment
Puppet Version: 6.8.0
Puppet Server Version: 6.5.0
OS Name/Version: Debian buster (10.x)
Since the change of allow_virtual to true in Puppet 6.8.0 some of our package resources behaved strangely and required to change the parameter back to the old default. At first we thought this only affected packages where the name and a provides value are identical (e.g. a resource to uninstall vim and install vim-nox now tried to unistall vim-nox since it also provides vim).
After installing a new server with the new Puppet version we noticed that the package bc had not been installed. It is defined with the simplest of package resources:
Looking at the provider source code we can see the relevant part here
with the constant used being defined further up in the file as
Running the command
on the affected system we can see the output the provider processes in the above code, a line might look like one of these
It is easy to see that all of these would also match the package resource named bc since the code just matches .name. within the comma-separated list of dpkg provides values, with no concern for matching a full name.
Virtual packages (provides values) should only match exactly. The default for allow_virtual should be false for at least the apt and dpkg provider since there are many packages in the apt repositories that have identical names and provides values which leads to broken systems when puppet starts uninstalling packages on ensure => absent.
Package resources are currently satisfied that they have found a matching package when they find the resource name as a substring in the list of provides values anywhere.