community.general.dnf_versionlock module – Locks package versions in dnf
based systems
Note
This module is part of the community.general collection (version 5.8.3).
You might already have this collection installed if you are using the ansible
package.
It is not included in ansible-core
.
To check whether it is installed, run ansible-galaxy collection list
.
To install it, use: ansible-galaxy collection install community.general
.
You need further requirements to be able to use this module,
see Requirements for details.
To use it in a playbook, specify: community.general.dnf_versionlock
.
New in community.general 4.0.0
Synopsis
Locks package versions using the
versionlock
plugin indnf
based systems. This plugin takes a set of name and versions for packages and excludes all other versions of those packages. This allows you to for example protect packages from being updated by newer versions. The state of the plugin that reflects locking of packages is thelocklist
.
Requirements
The below requirements are needed on the host that executes this module.
dnf
dnf-plugin-versionlock
Parameters
Parameter |
Comments |
---|---|
Package name spec to add or exclude to or delete from the This parameter is mutually exclusive with state=clean. Default: |
|
Do not resolve package name specs to NEVRAs to find specific version to lock to. Instead the package name specs are used as they are. This enables locking to not yet available versions of the package. Choices:
|
|
Whether to add (
Choices:
|
Notes
Note
The logics of the
versionlock
plugin for corner cases could be confusing, so please take in account that this module will do its best to give acheck_mode
prediction on what is going to happen. In case of doubt, check the documentation of the plugin.Sometimes the module could predict changes in
check_mode
that will not be such becauseversionlock
concludes that there is already a entry inlocklist
that already matches.In an ideal world, the
versionlock
plugin would have a dry-run option to know for sure what is going to happen. So far we have to work with a best guess as close as possible to the behaviour inferred from its code.For most of cases where you want to lock and unlock specific versions of a package, this works fairly well.
Supports
check_mode
.
Examples
- name: Prevent installed nginx from being updated
community.general.dnf_versionlock:
name: nginx
state: present
- name: Prevent multiple packages from being updated
community.general.dnf_versionlock:
name:
- nginx
- haproxy
state: present
- name: Remove lock from nginx to be updated again
community.general.dnf_versionlock:
package: nginx
state: absent
- name: Exclude bind 32:9.11 from installs or updates
community.general.dnf_versionlock:
package: bind-32:9.11*
state: excluded
- name: Keep bash package in major version 4
community.general.dnf_versionlock:
name: bash-0:4.*
raw: true
state: present
- name: Delete all entries in the locklist of versionlock
community.general.dnf_versionlock:
state: clean
Return Values
Common return values are documented here, the following are the fields unique to this module:
Key |
Description |
---|---|
Locklist after module execution. Returned: success and (not check mode or state is clean) Sample: |
|
Locklist before module execution. Returned: success Sample: |
|
Package name specs meant to be added by versionlock. Returned: success Sample: |
|
Package name specs meant to be deleted by versionlock. Returned: success Sample: |
Collection links
Issue Tracker Repository (Sources) Submit a bug report Request a feature Communication