The recent update to libcairo2 brought in an large number of unwanted gui packages:

   libdrm-intel1 (2.4.45-3)
   libdrm-nouveau2 (2.4.45-3)
   libdrm-radeon1 (2.4.45-3)
   libdrm2 (2.4.45-3)
   libegl1-mesa (9.1.3-6)
   libegl1-mesa-drivers (9.1.3-6)
   libgbm1 (9.1.3-6)
   libgl1-mesa-dri (9.1.3-6)
   libgl1-mesa-glx (9.1.3-6)
   libglapi-mesa (9.1.3-6)
   libllvm3.2 (3.2repack-7)
   libopenvg1-mesa (9.1.3-6)
   libpciaccess0 (0.13.1-2)
   libtxc-dxtn-s2tc0 (0~git20121227-1)
   libwayland-client0 (1.1.0-2)
   libwayland-server0 (1.1.0-2)
   libxcb-dri2-0 (1.9.1-2)
   libxcb-glx0 (1.9.1-2)
   libxcb-shape0 (1.9.1-2)
   libxcb-xfixes0 (1.9.1-2)
   libxdamage1 (1.1.3-2)
   libxfixes3 (5.0-4+deb7u1)
   libxxf86vm1 (1.1.2-1+deb7u1)

Of those, only libllvm3.2 (brought in above due to mesa) might have
any relevance on headless boxen.

Cairo is a dep for a number of non-gui packages for its pdf/ps/svg
output, such as gnuplot-nox and gd (and perhaps emacs*-nox in the future).

Gd, in particular, is frequently used for reports (such as by rrd) on
even small headless boxen.  Gnuplot-nox is similarly important.

That should not force in junk like wayland, x11 libs and mesa.

And they are junk on headless systems.

Whether it requires separate, blocking libcairo2-nox and libcairo2
packages, or separate related packages matching each of the cairo-foo
pkgconfig files, or one package for everything w/o gui deps and
another for everything with gui deps, deb needs to elide the gui deps
from non-gui uses of libcairo.

The list of unnecessary packages makes for more than 90 Mo of disk waste.

I'd like to second this request.  My print server should not need to
have mesa installed, and cups indirectly requires libcairo2.

It would be really nice to know if there's been any progress on
separating the GUI parts of libcairo2 from the non-GUI parts.  Today
brought another upgrade on my server that I had to block because I don't
need or want mesa installed on a server just because I have cups
installed.

There has not been any work towards this, and I think it's unlikely to happen
given how cairo is currently designed. The only solution I can think of is
having two builds, one that builds libcairo2-nox and another one that builds
libcairo2-full, then have both packages conflict with each other and provide
libcairo2. Then those that need the gl/egl bits can depend on libcairo2-full
unconditionally.

I'm not sure I like that though, just saying it's the only way I can think of of
solving this.

Emilio