Comment 21 for bug 725434

Summary of what was discussed and tested:

* shipping a libcairo2-gl which would conflicts,replaces,provides libcairo2 wouldn't work since provides are not versioned and that wouldn't satisfy the dependencies of most of binaries dependy currently on libcairo2
-> we need a new binary installable at the same time as libcairo2 and tweak ld paths

* the rules was updated to add a "gl" build flavor, it means cairo get built without gl and and an extra time with gl

* copying the gl build library in a new directory, that would work for runtime but is not enough for builds since the .pc and the .so don't point to the right variant, building with gl also creates some new cairo-gl.pc which need to be installed
-> we need a libcairo-gl-dev binary, the binary needs to be installable at the same time than libcairo-dev due to the same reason than the library (the provides are not versioned which would mean it can't be installed as a replacement)

* installing only the extra .pc in a different path wouldn't work since that would lead to inconsistencies in the cairo installation
-> the standard path needs to be used for those .pc

* If the .pc don't point to the right directory to build with gl it would mean wayland softwares that need cairo-gl would need hacks to point to the right directory

* The libcairo-gobject library should build with the correct variant to avoid have 2 different libcairo be loaded by libcairo-gobject users so we would probably need a libcairo-gobject-gl as well

The work starts being non trivial from there and it will lead to a solution that need hacks in softwares that want to use cairo-gl, does anybody has a better suggestion on what to do next?