User story #8230
Updated by Alexis Mousset over 8 years ago
This table only considers latest versions of techniques and generic methods. |_.name|_.OS|_.body|_.package list update frequency (yum update, etc.)|_.package list update frequency configurable?|_.handles installing "latest" version|_.available updates list frequency configurable?|_.handles "update or add if not installed"|_.execution frequency configurable (class persistence)| |rpm package installation 7.0 technique|RHEL/CentOS/SLES|generic_nobulk (in the technique)| 30 minutes | no | yes | yes (default is 60 minutes) | no | yes (default to 60 minutes)| |apt package installation 4.0 technique|Ubuntu/Debian|apt_nobulk (in the technique)|30 minutes | no | no | no | no | no| |package_install_* generic methods|Debian/Ubuntu|apt_get (in cfengine stdlib)|240 minutes| no | no | no | yes | no | |package_install_* generic methods|RHEL/CentOS|yum_rpm (in cfengine stdlib)|240 minutes| no | no | no | yes | no | |package_install_* generic methods|SLES|ncf_generic (in ncf stdlib)|240 minutes | no | no | no | yes | no | h2. Option 1 Proposed solution: Make one configurable package management method working properly and use it everywhere. * Use @ncf_generic@ body everywhere * Add available package list support to package_install_* ** Move rpm support to the generic method ** Add apt support * Make list update frequency configurable ** ncf configuration parameter ? ** Generic method parameter ? * Make a new version of RPM and APT package techniques using @package_install_@ Issues: Issues : * Some people implemented addupdate using directives with add+update on the same package, which cannot be handled properly with ncf reporting h2. Other notes We should have a plann to migrate to the new CFEngine package promises, which are now the default in 3.9. This should widely simplify our code on new CFEngine version (Rudder 3.2+). We can use if_version macro feature for this, which will be easier if all package operations are done in a single place.