Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
pkg.installed version parameter support for multiple conditions #48511
What does this PR do?
salt.states.pkg.installed supporting multiple version conditions.
Support for specifying a package condition in the version was recently added, this to enable more control over what versions will be installed.
This feature enables support for multiple conditions, this to allow version ranges and exclusions, which will enable more complex scenarios.
Hi @0w3w - Can you fix these pylint errors?
This change assumes comma and spaces are not used in a version string. Before it assumed prefix of a version string would not be
What happens if 14.0.1 or 17.0 is already installed, is it removed or upgraded or down-graded?
I am assume that compare version() is coming from the execution module still.
The following seems to be in only one place.
I would have thought that allow_updates bool check could be removed from other parts of the code if version string is prefixed with
You are right, the change assumes version numbers following the debian standard (https://www.debian.org/doc/debian-policy/#version) as well as the classic standard version format (major.minor.update.build), which covers, I would say, all of the versioning schemas. The REGEX part to detect the version string was not change though, so whatever version string was previously supported, will still be supported. The list of operators was expanded to support libsolv-based package managers and debian operators.
I have not updated the DOCO as I expect the first pkg provider to claim support for this, to update it. (opkg can be a great provider for this, I'll talk to Alejandro del Castillo, the maintainer of opkg, to see if he can implement this)
"What happens if 14.0.1 or 17.0 is already installed, is it removed or upgraded or down-graded? bar: ' > 12.0.0, < 15.0.0, != 14.0.1'"
Didn't make changes to compare_version, should come from the same module.
Regarding the allow_updates behavior, I purposefully maintained the existing logic to warranty backwards compatibility and didn't change existing behavior.
Thanks for the review!