On Wednesday 18 August 2004 10:20, Andreas Mueller wrote: >Ralf Corsepius wrote: >> On Wed, 2004-08-18 at 14:34, Andreas Mueller wrote: >> > Ralf Corsepius wrote: >> > > On Wed, 2004-08-18 at 11:28, Tim Waugh wrote: >> > > > I think this is something I'm going to have to let the >> > > > Fedora Legacy project address if need be -- but I do wish >> > > > that I hadn't started down this path in the first place. >> > > > >> > > > Sorry for the mess. >> > > >> > > Which mess? >> > > >> > > ghostscript/FC2 requires gtk2 and gdk_pixbuf2, ghostscript/FC1 >> > > requires their gtk1 counterparts, where is the problem? >> > >> > Think of a small text-only server with hylafax. Hylafax needs >> > ghostscript. And ghostscript pulls in urw-fonts, urw-fonts >> > needs /usr/X11R6/bin/mkfontscale (provided by >> > XFree86-font-utils) -> libXfont.so.1 (provided by XFree86-libs) >> > -> freetype. This is just *one* path of dependencies. The effect >> > is that I don't have a text-only server, now I have a lot of X >> > stuff that I don't want. >> >> That's what you already had *before* this new rpm. > >Correct, and I didn't like it before. > >> The new rpm added gdk-pixbuf and gtk+. Yes, this adds some more >> packages and wastes more disk space, but ... is it really >> important? Most of the packages required by gdk-pixbuf/gtk+ >> already are required elsewhere, so, though it is not nice, this >> should not be an actual problem. > >For me it is a problem. You can build a machine without a graphics > card, but need to have XFree86-Mesa-libGL installed if you want to > use ghostscript. > >(@Michael) >There is a seperate package for gsx, called ghostscript-gtk, but the >only file in this package is gsx itself. I see no problem that > *this* package depends on gtk and gdk-pixbuf, but why ghostscript? > >> > And the next >> > logical step is to install gtk+ and gdk-pixbuf? >> >> No, definitely not - As I said above, it isn't nice. >> >> My point is elsewhere: ghostscript for FC2 already depends on gtk2 >> (which comprises gdk-pixbuf-2). >> >> So if you consider the ghostscript update pulling-in gtk+ to be a >> packaging regression, then this regression had happened before the >> FC1/update package and also is present in FC2. >> >> => either there is a general packaging bug in both FC1/updates and >> FC2+, and packaging regression that needs to be addressed, or >> these dependencies are the nominal ghostscript dependencies you >> have got to learn to live with. > >I don't think that it is a ghostscript dependency. At least the >ghostscript ./configure can be instructed to not use X11 at all, but > I didn't look at Red Hat's patches, the ghostscript.spec is really > ugly. > >I think I have to consider other distributions for text-only > servers. > >Regards, >Andreas I have to agree with Andreas here. Having built gs as early as 2.5.2 from scratch on systems that don't have the video graphics facilities that linux has, I know that gs can function as a *print* medium interpretor only, one whose output is never intended to be viewed by any means other than sending it to a printer, so I believe that gs itself should remain pure and free from such visuals. If you want to see its output on screen, then by all means build the x emulations as a seperate optional package, but do NOT saddle the std gs distribution with eye candy thats totally worthless when its used as a translator between a file and the printers input data cable. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.24% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
