>>> 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
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
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