Doing some server benchmarking today on f10. And gnuplot has somehow acquired *way* to many unnecessary deps.
# yum -d1 install gnuplot
============================================================== Package Arch Version Repository Size ============================================================== Installing: gnuplot x86_64 4.2.3-1.fc10 fedora 2.2 M Installing for dependencies: GConf2 x86_64 2.24.0-1.fc10 fedora 1.7 M ORBit2 x86_64 2.14.16-1.fc10 fedora 196 k PolicyKit x86_64 0.9-3.fc10 fedora 173 k SDL x86_64 1.2.13-6.fc10 fedora 210 k alsa-lib x86_64 1.0.18-6.rc3.fc10 fedora 418 k atk x86_64 1.24.0-1.fc10 fedora 216 k cdparanoia-libs x86_64 10.2-2.fc10 fedora 53 k cups-libs x86_64 1:1.3.9-2.fc10 fedora 199 k gd x86_64 2.0.35-6.fc10 fedora 151 k gstreamer x86_64 0.10.21-2.fc10 fedora 789 k gstreamer-plugins-base x86_64 0.10.21-2.fc10 fedora 990 k gstreamer-tools x86_64 0.10.21-2.fc10 fedora 20 k gtk2 x86_64 2.14.4-3.fc10 fedora 4.3 M hicolor-icon-theme noarch 0.10-4 fedora 39 k jasper-libs x86_64 1.900.1-8.fc9 fedora 153 k libICE x86_64 1.0.4-4.fc10 fedora 54 k libIDL x86_64 0.8.11-1.fc10 fedora 93 k libSM x86_64 1.1.0-2.fc10 fedora 26 k libXcomposite x86_64 0.4.0-5.fc10 fedora 14 k libXcursor x86_64 1.1.9-3.fc10 fedora 29 k libXdamage x86_64 1.1.1-4.fc9 fedora 11 k libXfixes x86_64 4.0.3-4.fc10 fedora 15 k libXi x86_64 1.1.3-4.fc9 fedora 29 k libXinerama x86_64 1.0.3-2.fc10 fedora 13 k libXpm x86_64 3.5.7-4.fc9 fedora 57 k libXrandr x86_64 1.2.3-1.fc10 fedora 26 k libXv x86_64 1.0.4-1.fc10 fedora 20 k libjpeg x86_64 6b-43.fc10 fedora 143 k libogg x86_64 2:1.1.3-9.fc9 fedora 19 k liboil x86_64 0.3.14-1.fc9 fedora 148 k libtheora x86_64 1.0rc1-2.fc10 fedora 190 k libtiff x86_64 3.8.2-11.fc10 fedora 317 k libvisual x86_64 0.4.0-6.fc9 fedora 152 k libvorbis x86_64 1:1.2.0-5.fc10 fedora 212 k wxBase x86_64 2.8.9-1.fc10 fedora 673 k wxGTK x86_64 2.8.9-1.fc10 fedora 3.8 M
Transaction Summary ============================================================== Install 37 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 18 M Is this ok [y/N]: n Exiting on user Command
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.
../C
Curtis Doty wrote:
Doing some server benchmarking today on f10. And gnuplot has somehow acquired *way* to many unnecessary deps.
# yum -d1 install gnuplot
============================================================== Package Arch Version Repository Size ============================================================== Installing: gnuplot x86_64 4.2.3-1.fc10 fedora 2.2 M Installing for dependencies: GConf2 x86_64 2.24.0-1.fc10 fedora 1.7 M ORBit2 x86_64 2.14.16-1.fc10 fedora 196 k PolicyKit x86_64 0.9-3.fc10 fedora 173 k SDL x86_64 1.2.13-6.fc10 fedora 210 k alsa-lib x86_64 1.0.18-6.rc3.fc10 fedora 418 k atk x86_64 1.24.0-1.fc10 fedora 216 k cdparanoia-libs x86_64 10.2-2.fc10 fedora 53 k cups-libs x86_64 1:1.3.9-2.fc10 fedora 199 k gd x86_64 2.0.35-6.fc10 fedora 151 k gstreamer x86_64 0.10.21-2.fc10 fedora 789 k gstreamer-plugins-base x86_64 0.10.21-2.fc10 fedora 990 k gstreamer-tools x86_64 0.10.21-2.fc10 fedora 20 k gtk2 x86_64 2.14.4-3.fc10 fedora 4.3 M hicolor-icon-theme noarch 0.10-4 fedora 39 k jasper-libs x86_64 1.900.1-8.fc9 fedora 153 k libICE x86_64 1.0.4-4.fc10 fedora 54 k libIDL x86_64 0.8.11-1.fc10 fedora 93 k libSM x86_64 1.1.0-2.fc10 fedora 26 k libXcomposite x86_64 0.4.0-5.fc10 fedora 14 k libXcursor x86_64 1.1.9-3.fc10 fedora 29 k libXdamage x86_64 1.1.1-4.fc9 fedora 11 k libXfixes x86_64 4.0.3-4.fc10 fedora 15 k libXi x86_64 1.1.3-4.fc9 fedora 29 k libXinerama x86_64 1.0.3-2.fc10 fedora 13 k libXpm x86_64 3.5.7-4.fc9 fedora 57 k libXrandr x86_64 1.2.3-1.fc10 fedora 26 k libXv x86_64 1.0.4-1.fc10 fedora 20 k libjpeg x86_64 6b-43.fc10 fedora 143 k libogg x86_64 2:1.1.3-9.fc9 fedora 19 k liboil x86_64 0.3.14-1.fc9 fedora 148 k libtheora x86_64 1.0rc1-2.fc10 fedora 190 k libtiff x86_64 3.8.2-11.fc10 fedora 317 k libvisual x86_64 0.4.0-6.fc9 fedora 152 k libvorbis x86_64 1:1.2.0-5.fc10 fedora 212 k wxBase x86_64 2.8.9-1.fc10 fedora 673 k wxGTK x86_64 2.8.9-1.fc10 fedora 3.8 M
Transaction Summary
Install 37 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 18 M Is this ok [y/N]: n Exiting on user Command
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.
Personally, I think there's lower-hanging fruit.
-- Chris
On 12/02/2008 11:48 PM, Chris Snook wrote:
Curtis Doty wrote:
Doing some server benchmarking today on f10. And gnuplot has somehow acquired *way* to many unnecessary deps.
# yum -d1 install gnuplot
============================================================== Package Arch Version Repository Size ============================================================== Installing: gnuplot x86_64 4.2.3-1.fc10 fedora 2.2 M Installing for dependencies: GConf2 x86_64 2.24.0-1.fc10 fedora 1.7 M ORBit2 x86_64 2.14.16-1.fc10 fedora 196 k PolicyKit x86_64 0.9-3.fc10 fedora 173 k SDL x86_64 1.2.13-6.fc10 fedora 210 k alsa-lib x86_64 1.0.18-6.rc3.fc10 fedora 418 k atk x86_64 1.24.0-1.fc10 fedora 216 k cdparanoia-libs x86_64 10.2-2.fc10 fedora 53 k cups-libs x86_64 1:1.3.9-2.fc10 fedora 199 k gd x86_64 2.0.35-6.fc10 fedora 151 k gstreamer x86_64 0.10.21-2.fc10 fedora 789 k gstreamer-plugins-base x86_64 0.10.21-2.fc10 fedora 990 k gstreamer-tools x86_64 0.10.21-2.fc10 fedora 20 k gtk2 x86_64 2.14.4-3.fc10 fedora 4.3 M hicolor-icon-theme noarch 0.10-4 fedora 39 k jasper-libs x86_64 1.900.1-8.fc9 fedora 153 k libICE x86_64 1.0.4-4.fc10 fedora 54 k libIDL x86_64 0.8.11-1.fc10 fedora 93 k libSM x86_64 1.1.0-2.fc10 fedora 26 k libXcomposite x86_64 0.4.0-5.fc10 fedora 14 k libXcursor x86_64 1.1.9-3.fc10 fedora 29 k libXdamage x86_64 1.1.1-4.fc9 fedora 11 k libXfixes x86_64 4.0.3-4.fc10 fedora 15 k libXi x86_64 1.1.3-4.fc9 fedora 29 k libXinerama x86_64 1.0.3-2.fc10 fedora 13 k libXpm x86_64 3.5.7-4.fc9 fedora 57 k libXrandr x86_64 1.2.3-1.fc10 fedora 26 k libXv x86_64 1.0.4-1.fc10 fedora 20 k libjpeg x86_64 6b-43.fc10 fedora 143 k libogg x86_64 2:1.1.3-9.fc9 fedora 19 k liboil x86_64 0.3.14-1.fc9 fedora 148 k libtheora x86_64 1.0rc1-2.fc10 fedora 190 k libtiff x86_64 3.8.2-11.fc10 fedora 317 k libvisual x86_64 0.4.0-6.fc9 fedora 152 k libvorbis x86_64 1:1.2.0-5.fc10 fedora 212 k wxBase x86_64 2.8.9-1.fc10 fedora 673 k wxGTK x86_64 2.8.9-1.fc10 fedora 3.8 M
Transaction Summary
Install 37 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 18 M Is this ok [y/N]: n Exiting on user Command
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.
Why would they have to conflict with each other? Either you use gnuplot-cli as a baseline and build gnuplot-gui on top of that or if you want the option of not installing the CLI bits then you create gnuplot-common and then gnuplot-cli and gnuplot-gui on top of that. Many packages in Fedora are already split in this way.
Regards, Dennis
On Tue, Dec 02, 2008 at 05:48:29PM -0500, Chris Snook wrote:
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.
Personally, I think there's lower-hanging fruit.
If wxGTK had a subpackage with the media libraries, it would at least get rid of the GConf2 and gstreamer dependencies.
Miroslav Lichvar píše v St 03. 12. 2008 v 11:54 +0100:
On Tue, Dec 02, 2008 at 05:48:29PM -0500, Chris Snook wrote:
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.
Personally, I think there's lower-hanging fruit.
If wxGTK had a subpackage with the media libraries, it would at least get rid of the GConf2 and gstreamer dependencies.
wxGTK is mine, adding to my TODO
Dan
Chris Snook píše v Út 02. 12. 2008 v 17:48 -0500:
Curtis Doty wrote:
Doing some server benchmarking today on f10. And gnuplot has somehow acquired *way* to many unnecessary deps.
# yum -d1 install gnuplot
============================================================== Package Arch Version Repository Size ============================================================== Installing: gnuplot x86_64 4.2.3-1.fc10 fedora 2.2 M Installing for dependencies: GConf2 x86_64 2.24.0-1.fc10 fedora 1.7 M ORBit2 x86_64 2.14.16-1.fc10 fedora 196 k PolicyKit x86_64 0.9-3.fc10 fedora 173 k SDL x86_64 1.2.13-6.fc10 fedora 210 k alsa-lib x86_64 1.0.18-6.rc3.fc10 fedora 418 k atk x86_64 1.24.0-1.fc10 fedora 216 k cdparanoia-libs x86_64 10.2-2.fc10 fedora 53 k cups-libs x86_64 1:1.3.9-2.fc10 fedora 199 k gd x86_64 2.0.35-6.fc10 fedora 151 k gstreamer x86_64 0.10.21-2.fc10 fedora 789 k gstreamer-plugins-base x86_64 0.10.21-2.fc10 fedora 990 k gstreamer-tools x86_64 0.10.21-2.fc10 fedora 20 k gtk2 x86_64 2.14.4-3.fc10 fedora 4.3 M hicolor-icon-theme noarch 0.10-4 fedora 39 k jasper-libs x86_64 1.900.1-8.fc9 fedora 153 k libICE x86_64 1.0.4-4.fc10 fedora 54 k libIDL x86_64 0.8.11-1.fc10 fedora 93 k libSM x86_64 1.1.0-2.fc10 fedora 26 k libXcomposite x86_64 0.4.0-5.fc10 fedora 14 k libXcursor x86_64 1.1.9-3.fc10 fedora 29 k libXdamage x86_64 1.1.1-4.fc9 fedora 11 k libXfixes x86_64 4.0.3-4.fc10 fedora 15 k libXi x86_64 1.1.3-4.fc9 fedora 29 k libXinerama x86_64 1.0.3-2.fc10 fedora 13 k libXpm x86_64 3.5.7-4.fc9 fedora 57 k libXrandr x86_64 1.2.3-1.fc10 fedora 26 k libXv x86_64 1.0.4-1.fc10 fedora 20 k libjpeg x86_64 6b-43.fc10 fedora 143 k libogg x86_64 2:1.1.3-9.fc9 fedora 19 k liboil x86_64 0.3.14-1.fc9 fedora 148 k libtheora x86_64 1.0rc1-2.fc10 fedora 190 k libtiff x86_64 3.8.2-11.fc10 fedora 317 k libvisual x86_64 0.4.0-6.fc9 fedora 152 k libvorbis x86_64 1:1.2.0-5.fc10 fedora 212 k wxBase x86_64 2.8.9-1.fc10 fedora 673 k wxGTK x86_64 2.8.9-1.fc10 fedora 3.8 M
Transaction Summary
Install 37 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 18 M Is this ok [y/N]: n Exiting on user Command
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.
Dan
Dan Horák wrote:
Chris Snook píše v Út 02. 12. 2008 v 17:48 -0500:
Curtis Doty wrote:
Doing some server benchmarking today on f10. And gnuplot has somehow acquired *way* to many unnecessary deps.
# yum -d1 install gnuplot
============================================================== Package Arch Version Repository Size ============================================================== Installing: gnuplot x86_64 4.2.3-1.fc10 fedora 2.2 M Installing for dependencies: GConf2 x86_64 2.24.0-1.fc10 fedora 1.7 M ORBit2 x86_64 2.14.16-1.fc10 fedora 196 k PolicyKit x86_64 0.9-3.fc10 fedora 173 k SDL x86_64 1.2.13-6.fc10 fedora 210 k alsa-lib x86_64 1.0.18-6.rc3.fc10 fedora 418 k atk x86_64 1.24.0-1.fc10 fedora 216 k cdparanoia-libs x86_64 10.2-2.fc10 fedora 53 k cups-libs x86_64 1:1.3.9-2.fc10 fedora 199 k gd x86_64 2.0.35-6.fc10 fedora 151 k gstreamer x86_64 0.10.21-2.fc10 fedora 789 k gstreamer-plugins-base x86_64 0.10.21-2.fc10 fedora 990 k gstreamer-tools x86_64 0.10.21-2.fc10 fedora 20 k gtk2 x86_64 2.14.4-3.fc10 fedora 4.3 M hicolor-icon-theme noarch 0.10-4 fedora 39 k jasper-libs x86_64 1.900.1-8.fc9 fedora 153 k libICE x86_64 1.0.4-4.fc10 fedora 54 k libIDL x86_64 0.8.11-1.fc10 fedora 93 k libSM x86_64 1.1.0-2.fc10 fedora 26 k libXcomposite x86_64 0.4.0-5.fc10 fedora 14 k libXcursor x86_64 1.1.9-3.fc10 fedora 29 k libXdamage x86_64 1.1.1-4.fc9 fedora 11 k libXfixes x86_64 4.0.3-4.fc10 fedora 15 k libXi x86_64 1.1.3-4.fc9 fedora 29 k libXinerama x86_64 1.0.3-2.fc10 fedora 13 k libXpm x86_64 3.5.7-4.fc9 fedora 57 k libXrandr x86_64 1.2.3-1.fc10 fedora 26 k libXv x86_64 1.0.4-1.fc10 fedora 20 k libjpeg x86_64 6b-43.fc10 fedora 143 k libogg x86_64 2:1.1.3-9.fc9 fedora 19 k liboil x86_64 0.3.14-1.fc9 fedora 148 k libtheora x86_64 1.0rc1-2.fc10 fedora 190 k libtiff x86_64 3.8.2-11.fc10 fedora 317 k libvisual x86_64 0.4.0-6.fc9 fedora 152 k libvorbis x86_64 1:1.2.0-5.fc10 fedora 212 k wxBase x86_64 2.8.9-1.fc10 fedora 673 k wxGTK x86_64 2.8.9-1.fc10 fedora 3.8 M
Transaction Summary
Install 37 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 18 M Is this ok [y/N]: n Exiting on user Command
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.
Dan
fedora-server-list mailing list fedora-server-list@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
I'm gnuplot maintainer :) so my opinion is - ad a) there are people who wants additional functionality so it will be problem for them 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. ad c) I'm not sure how complicated the patch could be.
Ivana
Dan Horák píše v St 03. 12. 2008 v 12:02 +0100:
Miroslav Lichvar píše v St 03. 12. 2008 v 11:54 +0100:
On Tue, Dec 02, 2008 at 05:48:29PM -0500, Chris Snook wrote:
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.
Personally, I think there's lower-hanging fruit.
If wxGTK had a subpackage with the media libraries, it would at least get rid of the GConf2 and gstreamer dependencies.
wxGTK is mine, adding to my TODO
Done in Rawhide
Dan
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
server@lists.fedoraproject.org
-
Chris Snook -
Curtis Doty -
Dan Horák -
Dennis Jacobfeuerborn -
Ivana Varekova -
Miroslav Lichvar