Closed joshuaspence closed 3 years ago
This is a hack, and I prefer avoiding hacks :-)
Please provide details of the real world case you've encountered, in order to see if it's possible to solve it cleanly with some params.pp tweaks. On RHEL/Fedora, all of those split packages have different names, so there's no problem, so I'm assuming you're running something else and I'm interested in those details ;-)
(I consider defined() a hack because it's parse order dependent, so you will get different and/or unexpected results when setting ensure to 'installed' in one place and 'absent' in the other for the same resource... using ensure_resource() is still a hack, but at least doesn't have this particular problem)
We are using a custom build. The package is essentially equivalent to php5-cli
, php5-common
and php5-fpm
.
And have you tried to simply have that single package provide the 3 names? For rpms, it would be this in the spec file (for debs and ebuilds and ports, etc. I don't know) :
Provides: %{name}-cli = %{version}-%{release}
Provides: %{name}-common = %{version}-%{release}
Provides: %{name}-fpm = %{version}-%{release}
I'm not entirely sure that would work with puppet's package resource's yum provider, but it's worth a shot.
That's not what the issue is... the issue is that the following code does not work:
class { 'php::cli':
cli_package_name => 'my-package',
}
class { 'php::fpm::daemon':
package_name => 'my-package',
}
Indeed, the above code doesn't work. But if instead of 'my-package' twice, you set 'my-package-cli' and 'my-package-fpm', with the single 'my-package' properly "providing" those two names (as I illustrated with my rpm example), maybe it could work.
At this point, I would be more inclined to allow a special value for each package_name which would disable the package resource, and probably change any requirement to the common package when used. Would that work for you?
To avoid potential "duplicate resource definitions", wrap package declarations in a conditional block.