[Pkg-puppet-devel] Presenting dh-puppet

[Jérôme Charaoui]

Hello team,

As I mentioned on #debian-puppet this week, I've been working on a 
little project related to Puppet module packaging: dh-puppet. It's a 
debhelper addon to help reduce some of the tedium of packaging puppet 
modules in Debian.

It auto-installs the right module directories (data, manifests, types, 
etc.), README and REFERENCE docs, examples and maintscripts. It also 
generates a new substitution variable, ${puppet:Depends}, containing the 
module dependencies as defined in metadata.json.

To activate it in a source package, one just needs to add 
"dh-sequence-puppet-module" to build dependencies. No need to modify 
d/rules at all.

Before uploading it, I wanted to gather your feedback about how the 
dh-puppet should handle dependencies declared in metadata.json.

  * MODULE UPPER BOUNDS: A lot of modules define not only lower but also 
upper bounds for their dependencies. For example, it's common for 
modules to have a dependency on puppetlabs-stdlib in the form of ">= 
9.0.0 < 10.0.0". This means that if we update stdlib to v10 in the 
archive, many modules built with dh-puppet would also need to be 
updated. This would help ensure modules packages are always kept up to 
date and working, at the expense of maintenance load. Also, in practice, 
it seems to me that most modules *usually* work anyway with the next 
major version. So, should we honor the upper bounds for module dependencies?

  * PUPPET DEPENDENCY: Most module's metadata also declare a dependency 
on Puppet itself, in the "requirements" key. However, in the current 
state of affairs, only about 10% of the Puppet binary packages include 
"puppet" or "puppet-agent" in their dependencies. Should dh-puppet add 
puppet-agent to ${puppet:Depends} and if so, should it also honor the 
declared version requirements? This also might help to ensure the module 
packages are kept up to date as the Puppet agent/server packages 
continue to evolve. Alternatively, we could also choose to ignore this 
and only use "Enhances: puppet-agent" in the control files.

This dh-puppet project is only a beginning. If there's enthusiasm for 
it, I'm also planning to work on autodep8 integration. This is where it 
gets interesting, even for those of you who don't use module packages at 
all. Having autopkgtests on these packages will be a great help in 
identifying many Puppet module regressions in testing/sid. The issues 
identified (often trivial, like package name changes) will help us help 
module upstreams keep their modules compatible with the latest Debian, 
and make it easier and more convenient to puppetize our own testing/sid 
hosts.

What do you think?

-- Jérôme