Issue #12179 has been updated by Henrik Lindberg.
This means opening the gate to a very slippery slope... At the core, there must be a way to express versions across versioning schemes (package managers uses different ways of comparing versions). At Eclipse we created such a scheme called OmniVersion - http://wiki.eclipse.org/Equinox/p2/Omni_Version which allows versions to be self describing as there was a requirement to not have a centralized authority publishing "version scheme types" while still having all versions be comparable against any other with a non ambiguous ordering. (The document contains a couple of interesting examples). Sadly, even when having a lingua franca for versions and ranges, many publishers do not follow the rules of the scheme they say they use, or they change the scheme between versions. Irrespective of version ranges or not, a big problem is indirect dependencies - i.e. on additional packages being installed as part of installing the specified package. (Must confess I don't know what happens if puppet specifies package a = 1.0, and b=2.0 and installation of package a also installs b of version 3. To compute this correctly, a constraint solver is needed and it needs to know about all the available versions and all dependencies of the graph rooted at the set of things that are explicitly wanted (of specific versions or range of versions). The result is very time consuming to produce because all paths needs to be explored (i.e. lots of stuff needs to be downloaded to be examined). In practice this is not doable without using suitable repository technology. IMO, the best solution for someone that really cares about quality/security is to use their own curated/blessed repositories at all times as they otherwise have no clue what they are installing, or if a package also drags along unacceptable packages. (There are alternatives to this using something like black-listing and failing). With blessed repositories latest is typically used and exact version used for exceptions. When making overall changes to the blessed repository different environments can use different repositories (i.e. production uses a different set than test). When test is completed, the test repositories supplant the production ones. This both increases control/quality and reduces the need to constantly manage version ranges in manifests (only the explicitly stated exceptional versions needs to be updated when it is possible to remove the exception (or update it)). ---------------------------------------- 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-73106 Author: Steve Shipway Status: Needs Decision Priority: Normal Assignee: J.D. Welch Category: language Target version: Affected Puppet version: 2.7.9 Keywords: 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
