Rework Red Hat resolved package list to be more future proof

[jcpunk]

Pull Request (PR) description

CentOS Stream10 continues to have systemd-resolved in its own package.

This Pull Request (PR) fixes the following issues

[ekohl]

I'd lean to leaving it out of metadata.json until we can verify it in CI.

Having said that, all the Red Hat family except EL 8 have systemd-resolved. Perhaps we should set it in data/RedHat-family.yaml and then set it to ~ in data/RedHat-family-8.yaml to unset it again. That way we're future proof.

At least, I see that on Fedora 39 & 40 systemd-resolved is a separate package as well that we don't have in Fedora.yaml right now.

[ekohl]

Perhaps this is a good excuse to start supporting CentOS Stream 10 in our CI for acceptance tests, though I doubt there are Puppet packages available though :(

[jcpunk]

I can confirm there is no puppet agent for CS10. I pulled the one from Fedora to test it.

[jcpunk]

Took a stab at moving the package name up a slot per your comment.

I'm not sure how to fix the case to also work for newer fedora in the spec tests.

[evgeni]

I think the \d+ doesn't match. Did you try

Suggested change

	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], %w[Fedora \d+]
	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], %w[Fedora /\d+/]

But even then, I think %w[a b] always produces strings, so you'd need to be explicit and say

Suggested change

	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], %w[Fedora \d+]
	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], %w[Fedora 37], %w[Fedora 38]

Or maybe

Suggested change

	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], %w[Fedora \d+]
	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], ["Fedora", /\d+/]

[evgeni]

Wait, lol, no!

family is RedHat for Fedora too. So how about

Suggested change

	when %w[RedHat 7], %w[RedHat 9], %w[Debian 12], %w[Fedora \d+]
	when %w[RedHat 7], ["RedHat", 9..999], %w[Debian 12]

[evgeni]

Adding my brain dump from IRC:

19:19 < Zhenech> ooooh
19:20 < Zhenech> that major not mathing 9..999 is because it's a string, not an int
19:21 < Zhenech> mh, no, even that doesn't help
19:21 < Zhenech> fuckit
19:24 < Zhenech> okay, yeah, it constructs an Array, and that Array, as an object, must match, it can't contain matchers itself

[bastelfreak]

@jcpunk any chance you can add factsets to https://github.com/voxpupuli/facterdb as soon as CentOS offers vagrant images? That's required for us to properly test it.

[jcpunk]

Stream 10 is still gathering shape, vagrant may be a ways off.

[bastelfreak]

to quote from IRC:

15:38:29 Zhenech | https://mirror.stream.centos.org/10-stream/ is now a thing, so I assume containers should show up soon too and we can look into CI

[ekohl]

https://quay.io/repository/centos/centos?tab=tags has stream10-development and stream10-development-minimal. But as I said earlier, we'll need Puppet packages. rpm-software-management/mock#1383 is open, which is probably a requirement to easily build RPMs.

[jcpunk]

https://kojihub.stream.centos.org/koji/packageinfo?packageID=3493 is also probably worth noting here.

[ekohl]

Note our CI relies on Vagrant with Docker as a backend, so containers (which exist) are sufficient for that.

[bastelfreak]

Vagrant with Docker as a backend

Our CI uses docker directly, without vagrant (if you're speaking about the vox pupuli module pipeline). But we need Vagrant to generate factsets for facterdb (and that uses the facter ruby gems and doesn't require the puppet rpms).

[ekohl]

Our CI uses docker directly, without vagrant (if you're speaking about the vox pupuli module pipeline). But we need Vagrant to generate factsets for facterdb (and that uses the facter ruby gems and doesn't require the puppet rpms).

Oh yes, I indeed meant Beaker with Docker backend.