Use simple dependencies for 'apt' and 'yum-epel'

[salsa-dev]

@nictrix could you, please, explain why you added pessimistic dependencies for 'apt' and 'yum-epel' in metadata.rb by the 3212c18f64fc685e54c63b70d209462d9d064b3b in #14 ?

This creates dep conflicts in old chef-repos.

Can we use simple depends ?

depends 'yum-epel'
depends 'apt'

[nictrix]

@salsa-dev I was following semver.org best practices, which is to bring in any new changes from those cookbooks up until the next breaking change.

If this is not desirable we could change it back to no version numbers, but that communicates the cookbook works with all major versions of those cookbooks. And if we communicate that we'll need to add tests for each major version of apt and yum-epel.

[salsa-dev]

Here is the only code that is referencing apt or yum-epel cookbooks:

  case node['platform_family']
  when 'rhel', 'amazon'
    if node['platform_version'] =~ /^6/
      node.default['yum']['epel-testing']['enabled'] = true
      node.default['yum']['epel-testing']['managed'] = true
      include_recipe 'yum-epel'
    end
  when 'debian'
    include_recipe 'apt'
end

@nictrix could you explain what exactly should we run tests for ? apt and yum-epel cookbooks are tested on their own...

[nictrix]

Please see the CHANGELOG files for both cookbooks:

• apt: https://github.com/chef-cookbooks/apt/blob/master/CHANGELOG.md
• yum-epel: https://github.com/chef-cookbooks/yum-epel/blob/master/CHANGELOG.md

There are breaking changes between major versions; apt is on its 6th major version and yum-epel is on its 2nd major version. By referencing these cookbooks without version numbers it communicates to the netdata cookbook consumers that it supports all possible versions of those dependent cookbooks. And if we do that we should create kitchen suite's that run each of those possible versions with the netdata cookbook such as creating an integration cookbook for each major version which would reference the apt and yum-epel versions.

This testing scenario is more complex, but the completeness of such a test suite allows the netdata cookbook to remove version constraints.

---

Another option is to take whatever features netdata cookbook is using from those cookbooks and implement them into the cookbook itself, removing all dependencies. (not very DRY)

---

One other option is to use the less than or equal to constraint: https://docs.chef.io/config_rb_metadata.html#version-constraints

Then when the netdata cookbook needed to support a new version of apt or yum-epel it would require a new release version of the cookbook.

---

After writing all this out I think the best option is the less than or equal to constraint

depends 'yum-epel', '<= 2.1.2'
depends 'apt', '<= 6.1.4'

It will miss the patches that get pushed, but since netdata cookbook is tested it should be satisfactory.

[salsa-dev]

I have read the CHANGELOGs for apt and yum-epel cookbooks and couldn't find any breaking changes for the netdata-cookbook: these cookbooks are only used once in the code block by including the default recipes of them, no other recipes and resources are being used throughout the netdata-cookbook.

The apt and yum-epel cookbooks are utilized to update the apt package cache and to set epel repository and update its cache.

This is all just for installing up-to-date plugin_packages and compile_packages that are actually available for any operating system by default: git bash curl iproute python python-yaml + autoconf autogen automake gcc make zlib1g-dev uuid-dev libmnl-dev netcat pkg-config

Adding to that the purpose of the apt and yum-epel cookbooks (default recipe) is not going to change:

• The yum-epel cookbook takes over management of the default repositoryids shipped with epel-release.
• The apt cookbook includes recipes to execute apt-get update to ensure the local APT package cache is up to date.

Therefore:

we should create kitchen suite's that run each of those possible versions with the netdata cookbook such as creating an integration cookbook for each major version which would reference the apt and yum-epel versions.

No matter which versions of the cookbooks netdata-cookbook is using it will work for its original purpose.

Another option is to take whatever features netdata cookbook is using from those cookbooks and implement them into the cookbook itself, removing all dependencies. (not very DRY)

There is nothing to implement because netdata-cookbook is just using apt and yum-epel cookbooks default functionality.

One other option is to use the less than or equal to constraint..

This could be an option as if we only trust to run apt-get update/yum update to the tested major versions. And that may be the truth and some burden to maintain.

Would you agree to trust apt and yum-epel cookbooks upto but not including next major versions?

depends 'yum-epel', '< 3.0.0'
depends 'apt', '< 7.0.0'

Just reminding that this is to allow usage of netdata-cookbook in old chef-repos.