[Pkg-puppet-devel] Presenting dh-puppet

[Thomas Goirand]

Hi Jérôme!

On 3/2/24 03:09, Jérôme Charaoui wrote:
> 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.

Thanks for that work.

>   * MODULE UPPER BOUNDS: [...]  So, should we honor the upper bounds
> for module dependencies?

As with other languages: I don't think so. The upper bounds are for 
hypothetical breakages, which mostly never happen.

>   * 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?

I don't mind if puppet-agent is in depends (I don't think it maters), 
but I do not really want the version to be honored. It's IMO the same 
type of breakage as the upper bound: it's useless and annoying.

> 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.

That would really help a lot to have autopkgtest in all modules indeed. 
I maintain maybe 90 puppet modules, and it's hard to know if one breaks 
with the new release. I currently don't run tests at all, I'd love to 
have them during the package build AND in autopkgtest. This would help a 
lot to find breakages early.

Note that all OpenStack puppet module upstream have extensive unit 
testing, that hopefully, are Debian compatible.

So again, thanks a lot for this work.

Cheers,

Thomas Goirand (zigo)