Do we really need a bundled protobuf? We generally have the policy to not allow this.

@globin I have a hunch that we can avoid the built-in protobuf if we configure opencv to statically link against ${pkgs.protobuf3_1}/lib/libprotobuf.a. My hunch is based on the same resolution of BVLC/caffe#1917 where they have the same issue.

I didn't know how to do that though so I went with the easier option of using the built-in protobuf.

I made another attempt at fixing the protobuf issue but failed.

A quick way to reproduce the bug is to checkout that branch and run:

$ nix-build -A haskellPackages.opencv-extra
...
[libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already exists in database: caffe.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:1272] CHECK failed: generated_database_->Add(encoded_file_descriptor, size): 
terminate called after throwing an instance of 'google::protobuf::FatalException'
  what():  CHECK failed: generated_database_->Add(encoded_file_descriptor, size): 

So for the time being I think it's best to go with this PR and use the bundled protobuf. We can always come up with a better fix later.

We had the same issue with mesos, check c2ce384

This is the issue that we're running into: opencv/opencv_contrib#823

I tried the last suggestion in that issue which is to patch caffe to rename libproto.a -> libcaffeproto.a. Unfortunately that didn't help.

So for now I disabled the troublesome dnn_modern contrib module.

I will squash all commits into a single commit and do a force push.

This is ready to be reviewed again.