Re: HEADS-UP: Modular X11 (ALL maintainers, please read)

["James R. Phillips" <antiskid56-cygwin at yahoo dot com>]

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