--- "James R. Phillips" wrote: > --- "Yaakov S (Cygwin Ports) wrote: > > > I have been working on packaging the new, modular X11R7.0 for Cygwin for > > the last few weeks. > > Mega-gold-stars for you! > > > > SECOND, the following packages install into /usr/X11R6. These should be > > repackaged into /usr ASAP after the X11R7.0 upgrade: > > [...] > > > ghostscript-x11 [2] > > OK > > [...] > > > [2] ghostscript currently provides two sets of executables; a non-X > > version in /usr and an X version in /usr/X11R6. What is the reasoning > > for this, and is it really necessary? > > It is necessary if you want to have a ghostscript version that does not > depend > on X. Maybe this will be less important now, with the modular X, but I > suspect > it is still important. ghostscript functions just fine as a command-line > filter, so many folks would prefer to have the non-X version. The X version > has the additional capability to write a bitmap rendering to an X client - I > think that is about the only difference. > > I'll take a look at how Debian or Ubuntu handle it, and see if I can > shamelessly copy their ideas. > > Jim Phillips >
OK, I looked at debian, and to my surprise they don't offer a version of ghostscript that doesn't depend on X. And this in spite of the fact that they haven't switched to the modular X-server yet (although they will shortly). So I wonder if cygwin really needs to support a non-X version of ghostscript in the future. I have no clue whether it might be able to live with a small subset of the newly-modular X libraries. Thoughtful comments would be appreciated. If we keep both versions, we need a way to keep them from overwriting each other, because they could both be installed. This needs to be considered because cygwin setup doesn't have a concept of conflicting packages. The current arrangement just puts them in different paths, and lets the $PATH environmental variable sort out which one you will get. I don't think the alternatives sytem really does what you want for this set of packages, because one is _not_ just as good as the other, i.e., if the version linked to X is installed, you definitely want to use it. It should probably be taken care of using a symlinks in pre- and post-install scripts. The desired behavior would be to use the non-X version only if it is the only version installed; and otherwise to set the symlink to the version that is linked to X. jrp