In this case, the server admin already has the desired base libX11 and libpng stuff. So only the jpeg and related imaging libs are probably reasonable. But definitely *not* the multimedia and various UI elements.
None of the direct dependencies in that dependency tree are unreasonable. There are three ways to make them go away:
a) Disable the GUI bits in gnuplot at build time, and remove the requisite dependencies. This will piss off anyone who actually uses those features.
b) Create gnuplot-cli and gnuplot-gui packages that conflict with each other. This will piss off lots of people.
c) Make gnuplot smart enough to tell at runtime whether or not the GUI bits are installed, and properly handle the case where someone asks for them but they're not there. Abstract the GUI calls into a gnuplot-gui package, which has most of the dependencies. Upstream won't care to do this themselves, but they'll probably take the patch if you write it yourself, it's clean, and it's completely bug-free.
I have talked to gnuplot maintainer and she is looking at that.
I'm gnuplot maintainer :) so my opinion is - ad a) there are people who wants additional functionality so it will be problem for them
hidden change in functionality is a no-go
ad b) the main part of gnuplot is in one binary so there is no easy way how to split it - the binary requires are the cause of the large require list, but there is no separated CLI part now (no executable anything), - so if there will be no change the package can't be divided. I'm not sure whether there could be gnuplot build twice - like busybox package one of them with present configuration and the other something like "minimal" for server purposes - and rename binary file and use it for server purposes.
the "alternatives" mechanism can be used here to keep the executable name stable
ad c) I'm not sure how complicated the patch could be.
and whether the upstream will accept such patch, but for long-term solution it could be preferred
Dan