Prototype: packagesmatching(package_regex, version_regex, arch_regex, method_regex)

Return type: data

Description: Return a data container with the list of installed packages matching the parameters.

This function searches for the anchored regular expressions in the list of currently installed packages.

The return is a data container with a list of package descriptions, looking like this:



  • package_regex: string - Regular expression (unanchored) to match package name - in the range: .*
  • version_regex: string - Regular expression (unanchored) to match package version - in the range: .*
  • arch_regex: string - Regular expression (unanchored) to match package architecture - in the range: .*
  • method_regex: string - Regular expression (unanchored) to match package method - in the range: .*

Argument Descriptions:

  • package_regex - Regular expression matching packge name
  • version_regex - Regular expression matching package version
  • arch_regex - Regular expression matching package architecutre
  • method_regex - Regular expression matching package method (apt-get, rpm, etc ...)

The following code extracts just the package names, then looks for some desired packages, and finally reports if they are installed.

IMPORTANT: The data source used when querying depends on policy configuration. When package_inventory in body common control is configured, CFEngine will record the packages installed and the package updates available for the configured package modules. In the Masterfiles Policy Framework package_inventory will be configured to the default for the hosts platform. Since only one body common control can be present in a policy set any bundles which use these functions will typically need to execute in the context of a full policy run. If there is no package_inventory attribute such as on package module unsupported platforms or when a policy entry file other than is selected with the --file -f argument then the legacy package methods data will be used. At no time will both standard and legacy data be available to these functions.

body common control

      bundlesequence => { "missing_packages" };

bundle agent missing_packages
    # List of desired packages
    "desired" slist => { "mypackage1", "mypackage2" };

    # Get info on all installed packages
    "installed" data => packagesmatching(".*",".*",".*",".*");
    "installed_indices" slist => getindices(installed);

    # Build a simple array of the package names so that we can use
    # getvalues to pull a unified list of package names that are installed.
      string => "$(installed[$(installed_indices)][name])";

    # Get unified list of installed packages
    "installed_names" slist => getvalues("installed_name");

    # Determine packages that are missing my differencing the list of
    # desired packages, against the list of installed packages
    "missing_list" slist => difference(desired,installed_names);

    # Report on packages that are missing, installed
    # and what we were looking for
    "Missing packages = $(missing_list)";
    "Installed packages = $(installed_names)";
    "Desired packages = $(desired)";

This policy can be found in /var/cfengine/share/doc/examples/ and downloaded directly from github.


"all_packages" data => packagesmatching(".*", ".*", ".*", ".*");

Refresh rules: * installed packages cache used by packagesmatching() is refreshed at the end of each agent run in accordance with constraints defined in the relevant package module body. * installed packages cache is refreshed after installing or removing a package. * installed packages cache is refreshed if no local cache exists. This means a reliable way to force a refresh of CFEngine's internal package cache is to simply delete the local cache:


Or in the case of legacy package methods:


History: Introduced in CFEngine 3.6

See also: packageupdatesmatching(), Package information cache tunables in the MPF