Puppet

Personally, I’m not convinced that the dpkg provider should be considered versionable. Really, the provider has no capability to select a package version, and (unless there’s a big chunk of code somewhere in the provider I haven’t noticed) the provider isn’t even capable of detecting that the package that it’s going to install will or won’t satisfy the version requirement prior to installing the package file.

Certainly, the error message given is not intuitive, and I’ll go and fix that now, but I’m not comfortable just adding a versionable? => true to the provider without some further discussion.

I’ve put explicit versioning? methods into all package providers, in r2538.

The “right” solution here is to use ‘has_features :versionable’, which I was planning on doing, um, soon. The Package type needs to define a ‘versionable’ feature, with a description but no method requirements, and then the rest of the system should be modified to use that feature, instead of the ‘versionable?’ method.

By examining the user type, I’m pretty sure I can see how to declare the feature in the type (“feature :versionable”) and specify which types are happy to deal with versioning (“has_features :versionable” — I think a gramatically correct alias ‘has_feature’ would be nice). I’m not so sure on how to handle the detection and management of the lack of the feature, though. The user type only constrains an attribute/parameter/whatever by the presence of the feature. Deep examination of the ProviderFeature code suggests that a ? method is created on the provider when the feature is first defined; is that correct? In which case there’s no need to change the main code of the type at all (other than to add the “feature :versionable” line). I’d just play with it and let the tests be my guide, except I have no idea whether the test coverage is complete in that area…

Yes, it creates a class method ‘versionable?’, and you can also call ‘feature?(:versionable)’, but these are both class methods (on the provider), not instance methods. So, you can just change the instance methods to call ‘self.class.versionable?’, or you can find the places where they’re called and replace the instance method calls with class method calls.

You’re correct that ‘has_feature’ would also be nice.

All of the feature code is in util/provider_features.rb. Note that the implementation is somewhat strange — every resource type that defines features creates a module that is then included in each provider. Look in the ‘feature_module’ method — you’ll need to add your ‘has_feature’ method there, defining it like the others.

Also note that both the provider features module and the per-type module are used to extend classes, meaning that they create class methods, not instance methods.

Please add comments documenting your findings as you figure things out. I tried to make it clear, but I expect I failed.

Nice trick tying the feature to the availability of another method, but didn’t we agree on IRC that the dpkg provider isn’t actually versionable, since it isn’t capable of selecting a different version than the one provided in the source parameter?

Yep. That’s what I retracted this stupid “fix” in r2618.

Aaah, I see. The commit notification for r2618 hadn’t come through yet.