Dependency loop caused by dependency on the module's apt::source

[tdb]

puppet-icinga/manifests/repos/apt.pp

Line 30 in ba5a01b

Apt::Source[$repo_name] -> Package <| title != 'apt-transport-https' |>

I've had a dependency loop caused by this line, and I'm not sure that I understand it. It looks like it creates a dependency for all packages except apt-transport-https on the apt::source it creates.

The loop I got looked roughly like:

  File[/etc/apt/sources.list.d/icinga-stable-release.list] =>
  Apt::Setting[list-icinga-stable-release] =>
  Apt::Source[icinga-stable-release] =>
  Package[puppet] =>
  Class[Site::Ubuntu] =>
  User[root] =>
  File[/etc/apt/sources.list.d/icinga-stable-release.list]

It is unique to my setup, but that dependency between the Apt::Source and Package[puppet] was caused by the above line.

The line was originally introduced in 2ddb3fb and has been moved around and slightly changed a few times since then.

If the Package resources in this module need to depend on the Apt::Source it creates then I think that should be done instead, rather than applying it to all packages across all modules.

[lbetz]

Arrg ok. But the first thing that comes to my mind is, why the puppet package is managed? And is it the puppet agent? If so, it isn't the AIO agent package from puppet. Managing the puppet agent package with puppet sound strange to me. But to fix it quickly, would be to manage the repositories on yout own and disable manage_repos in the icinga classes.

[lbetz]

Do you use some other upstream modules and the puppet package is manage by these modules? Maybe there could be an option to disable the package management?

[tdb]

I can work around it, that's fine. Another simple example:

File[/etc/apt/sources.list.d/icinga-stable-release.list] =>
Apt::Setting[list-icinga-stable-release] =>
Apt::Source[icinga-stable-release] =>
Package[tcsh] =>
User[root] =>
File[/etc/apt/sources.list.d/icinga-stable-release.list]

In this case the user root is managed and has the tcsh shell set, so depends on the package. Yes, a slightly contrived example, but just proves the point.

In my opinion a module shouldn't be making such a blanket dependency to say that all package resources depend on the one apt source that's been created. The class installing the icinga packages could have a tag called icinga, and then the collector used here could match all package resources with that tag, rather than every package. Just throwing ideas around...

[lbetz]

You are right. I have shied away from it so far because three other modules are involved and also repos, which may have nothing to do with packages around Icinga. Feel free and check out pr #128.