Error resolving backup dependency.

[shrinathaithal]

metadata.rb specifies backup v0.2.1 but that version isn't available.
https://supermarket.chef.io/cookbooks/backup#changelog

Am I missing anything?

[ramonskie]

yes as you can see in https://github.com/ramonskie/bamboo/blob/master/Berksfile#L5
i depend on the much superior backup cookbook from @damm

[rylarson]

The problem is that when you try to resolve this cookbook using Berkshelf, it fails because the backup cookbook you are using is not available in the supermarket. When you publish your cookbook, supermarket thinks you are using the backup cookbook from Supermarket.

Try this sample Berksfile

source 'https://supermarket.chef.io'

cookbook 'bamboo'

It will fail to resolve. It will succeed if you add:

source 'https://supermarket.chef.io'

cookbook 'bamboo'
cookbook 'backup', git: 'https://github.com/damm/backup', tag: '0.2.6'

But this causes another problem. If any other cookbook in your Berksfile uses the backup cookbook from the Supermarket, it will cause those recipes to fail because the resources are not API compatible.

Is there a reason we cant just use the backup cookbook from the public supermarket?

[aogail]

@ramonskie If you already realize this, please forgive my explanation, but it seems like the breakage may not be clear: Currently the bamboo cookbook is simply broken for everyone out of the box, because of the backup cookbook dependency. When someone tries to use it, it results in an error like this:

$ cat Berksfile 
source "https://supermarket.chef.io"

cookbook 'bamboo', '~> 1.7.0'
$ berks install
Resolving cookbook dependencies...
Fetching cookbook index from https://supermarket.chef.io...
Unable to satisfy the following requirements:

- `backup (= 0.3.0)` required by `bamboo-1.7.0`
Unable to find a solution for demands: bamboo (~> 1.7.0)

This is extremely difficult to diagnose particularly because there is in fact already a cookbook named backup in the public Supermarket. You have to run across the fact that bamboo has a Berksfile that specifies a different backup cookbook than the published one -- none of which is exposed in Supermarket's UI, because it does not look at Berksfiles.

A cookbook published to Supermarket (bamboo in this case) can't depend upon a cookbook that is not also published to Supermarket (backup in this case). If it does, then the dependency can't be resolved without a hacky workaround.

[damm]

https://github.com/ramonskie/bamboo/blob/master/Berksfile

[ramonskie]

@damm i really don't know why so many ppl have issues with it using berks to upload cookbooks.
maby we should rename backup to

• backupv2
• backupminion

or something like that

[mvdkleijn]

@aogail can you make sure you're using the Berksfile for this cookbook and not setting your own or something? It would appear you're using an outdated or customized Berksfile which is what would be causing the berks install issues.

Berks is a normal part of the Chef ecosystem and resolving dependencies through a Berksfile setting is perfectly acceptable. Not all Chef cookbooks have a supermarket presence for various reasons and I personally don't think it makes sense to limit oneself to just supermarket cookbooks.

[rylarson]

@mvdkleijn,

The Berksfile for this cookbook works fine. The problem is when you try to use the cookbook in another Berksfile. There are a couple of problems:

1. Cookbooks on the supermarket are intended to have all of their dependencies be able to be resolved from the sources in the Berksfile. If you go to the supermarket page for bamboo, it tells you the way to use it is to just add the single cookbook 'bamboo' entry to your Berksfile because Supermarket expects cookbooks in the Supermarket to have dependencies that resolve via the Supermarket. The fact that this one doesn't is just unusual, and therefore unexpected. The git url is a bit of a hack, as you have to depend on the user of the underlying VCS to make tags/branches so that you can depend on specific versions.
2. The really simple case where you are only using this cookbook in your Berksfile is not that big of a deal. The real problem arises when you are using more than just Bamboo. If you try to use the Bamboo cookbook with another cookbook that depends on backup from the community site (as most cookbooks that use a backup cookbook do), it will break because the resources are not API compatible between the @damm backup cookbook and the backup cookbook on the community site. The intersection of this Bamboo cookbook and every cookbook on the supermarket that depends on backup are broken together.

We tried to get a conversation going with @damm to fix the underlying problem of the backup cookbook having a name collision. For better or for worse, he doesn't seem interested in changing the name to make it easier for people to use. See these issues for background:

https://github.com/damm/backup/issues/31
https://github.com/damm/backup/issues/40

[rylarson]

I think there are a couple of simple solutions to this problem:

1. Remove the backup dependency from the cookbooks metadata.rb file, and document that if you want to use the backup recipe, that you need to depend on the @damm backup cookbook

or

1. Split the backup recipe into a new cookbook (maybe bamboo_backup or something) that depends on the @damm backup cookbook.

Both of these accomplish the goal of not breaking dependency resolution and not causing conflicts with other cookbooks.

[aogail]

@mvdkleijn I was in the middle of typing something similar to what @rylarson just wrote, then saw his note. I will just add that according to Berkshelf devs, using SCM and path locations in the Berksfile is for development convenience and is not recommended for use in published cookbooks. See berkshelf/berkshelf#1408 for example.

[damm]

@ramonskie As you know I have the backup_lwrp namespace if you prefer we can release to a unique namespace for you like bamboo_backup or backuplwrp.

I have no real preference whatever works best for you.