On 2014-12-02 24:44, Kylo Ginsberg wrote:
A recent pull request to puppet [1], in support of richer version
matching for the 'pkg' package provider, led me to discover some older
proposals, e.g. [2], for allowing flexible version matches, e.g.. to
allow something like:
package { 'foo': ensure => '> 1.2.3' }
The issues aren't identical -- the current pull is more about implicit
matches against newer available versions, whereas the older proposal is
about explicitly specifying version ranges -- but they share the intent
to allow for flexible version matching for packages.
So, I'd like to get input on this topic. E.g. is something along these
lines desirable, or is it seen as too risky (e.g. due to version drift)?
And what packaging tools can effectively support flexible version
matching? Is there a common core of this functionality which we could
meaningfully define across a useful set of packaging tools?
Thanks!
[1]: https://github.com/puppetlabs/puppet/pull/2200
[2]: https://tickets.puppetlabs.com/browse/PUP-1519
Supporting anything but exact version, or abstract version like "latest"
means traveling down a road filled with semantic pot-holes.
The first problem is that a package is largely free of implementation
concerns (i.e. provider), and there is no universal version scheme.
Thomas Hallgren and I worked on this problem for the Eclipse p2
provisioning system (supports ranged dependencies, reverse dependencies,
filters, and much more). We came up with a Omniversion -
https://wiki.eclipse.org/Equinox/p2/Omni_Version a way to canonically
describe versions and version schemes to allow them to be
correctly compared.
This made it possible to parse versions with the semantics of a wide
variety of version-schemes.
I really hope we do not have to go down that road... (If you think "How
hard can it be?" - see the description of Omniversion to get a feel for
some of the complexities).
Thus, if we back away and versions (single, or range) has to be
describes as an opaque string - essentially an instruction to the
underlying packaging system that represents the notion of "acceptable
version", then it can be made to work, but the problem of correctly
describing the version is now up to the user (i.e. the resource is
specific to a particular packaging system). We probably already have
this problem since packages are versioned differently in different
package managers. What will probably happen with allowing support for
version ranges is that more complexity needs to be resolved in puppet
manifests.
Tough choices...
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/ldg181%24fo3%241%40ger.gmane.org.
For more options, visit https://groups.google.com/groups/opt_out.
