[Pkg-puppet-devel] Presenting dh-puppet

[Antoine Beaupré]

On 2024-03-01 21:09:53, Jérôme Charaoui wrote:

[...]

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

I would rather not, agreed with zigo on this.

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

I wouldn't add a hard dependency, but not a strong LOGAF. My thinking is
we might run some CI job or linting task that does not require the
agent, but that could be usefully ran against the installed module...

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

autopkgtest would be *awesome*! I have slight concerns about the
direction you were taking with that however; on IRC, you seemed to be
saying you want to write manifests specific for the autopkgtest
suite... For me, we should just run the upstream test suite
directly.

I understand this might be more complicated to implement or might just
fail, so you're leaning towards writing a simple "smoke test" with a
`.pp` manifest, and I think that's a good short-term fix. But even if we
do go *that* way, I would much rather see those in the upstream
`examples/` directory, where it can (eventually!) be submitted upstream,
than having a permanent divergence in the `debian/tests/` dir.

Thanks!

a.

-- 
Don't just do something, sit there.
                        - Sylvia Boorstein