Issue #12179 has been updated by Reid Vandewiele.
Stephen Jones wrote: > Don't worry about the "philosophy" - we need this and it's natural. ----- This simple functionality would enable significant patch-related use cases that currently just aren't possible due to the requirement of iterating EXACTLY what package version to ensure, rather than just a defined security requirement. Puppet is philosophically about being able to specify *what you care about* and nothing else. There are many use cases where what people care about is ONLY that a package be newer than a known vulnerable version, but the specific version beyond that is not important. Using Puppet to specify a minimum version packages must be at based on security advisories or bulletins, for example. With regards to the objection that this opens the door to violation of the principle of least surprise due to difficulties in determining what it means for one package version to be "newer" than another, I would like to point out as case studies the following packaging policies for Debian and RedHat, respectively. * [Debian Policy Manual](http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version) * [Fedora Package Name Guidelines](http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning) If people are implementing poorly versioned packages then OF COURSE this would be useless. It's a feature for people who care about packages and versioning. The point is that standards for determining when one package is newer than another exist and are well-defined. Furthermore, worrying about that is an implementation level detail, and should not block a decision on this issue. To resurrect what I think is the **actionable** and **decision-needed** aspect of this ticket: ----- # Feature Request # Implement a `minimum_versionable` feature for the Package type which can optionally be implemented by providers. The `minimum_versionable` feature should be described as: <pre> feature :minimum_versionable, "The provider is capable of selectively upgrading to the latest version of a package if and only if the installed version is less than a provided minimum version. Using a minimum version of 1.5-2 as an example, this feature is used by specifing `>= 1.5-2` as the desired value for the package." </pre> Proof of Concept implementation: [https://github.com/reidmv/puppet/compare/master...8975_package_feature_minimum_versionable](https://github.com/reidmv/puppet/compare/master...8975_package_feature_minimum_versionable) ---------------------------------------- Feature #12179: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number https://projects.puppetlabs.com/issues/12179#change-96932 * Author: Steve Shipway * Status: Needs Decision * Priority: Normal * Assignee: J.D. Welch * Category: language * Target version: * Affected Puppet version: 2.7.9 * Keywords: ux * Branch: ---------------------------------------- It would be helpful if the 'ensure' parameter to the Package resrouce could also specify 'at least version **x**' and 'no later than version **y**' as well as 'latest version', 'installed' (IE, any version) or a specific version number. EG: package { 'foo': ensure=>'>1.0' } would act as 'latest' if the current package was uninstalled or version before 1.0, but would act as 'installed' otherwise. Similarly, package { 'foo': ensure=>'<4.0' } would act as 'installed' if version is <4.0 but would produce an error otherwise. This would allow us to set a manifest to avoid packages with known problems in a certain version, but not upgrade unless necessary. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
