Flexible version matching for packages?

[Kylo Ginsberg]

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

--

Kylo Ginsberg

ky...@puppetlabs.com

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://bit.ly/pupconf14

[Jason Antman]

I had a pull request [1] to "fix" version comparison for yum and rpm packages, as the current behavior is far from what yum does. The PR's more or less stalled waiting for me to rework it, but I feel pretty strongly that before we implement flexible versioning like this, we need to make sure version comparison is done right - not all package types use semver, which seems to be the assumption that everything using the Package type makes (for example, yum/rpm actually sorts "1.2.999" *after* "1.2.11a").

my 2 cents:
- explicit version specification is a very good thing, if version comparison is reliable and in step with the underlying package system. I'd love to be able to specify ">= 1.2.3"
- implicit matches feel wrong to me... I'd be concerned that this would break things for a lot of people. And unfortunately, the people most likely to have things broken are the people who are already "scared" of Puppet doing things they don't want, so they manually peg every package to a specific version and tell their hesitant management that everything will be fine...

-Jason

[1] https://github.com/puppetlabs/puppet/pull/2262

--
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 puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALsUZFH6ZEFDq1O-5AM9%2B6PNZn%2Be346GbrG-442%2BBJ8%3DVMeTow%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Felix Frank]

On 02/12/2014 12:18 PM, Jason Antman wrote:
>
> - explicit version specification is a very good thing, if version
> comparison is reliable and in step with the underlying package system.
> I'd love to be able to specify ">= 1.2.3"

I'm torn. The sync action would be "update to latest", no? So I'm not
sure the overhead is justified, seeing as puppet can do that without
problems already.

What the >$VERSION scheme introduces is behavioral ambiguity, I feel,
and while it may seem neat to be able and jot such information down in a
module, again, the benefit is limited, seeing as such matchers won't stack.

Btw., from PUP-1519

package { 'foo': ensure=>'<4.0' }

would act as 'installed' if version is <4.0 but would produce an error
otherwise.

This doesn't fit with puppet's MO at all. Out-of-sync properties should
really have a way to get in sync, imho, and provoking resource failures
to notify the user of manual actions required just feels very wrong.

Regards,
Felix

[Henrik Lindberg]

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