HEADS-UP: Modular X11 (ALL maintainers, please read)
James R. Phillips
Mon Apr 17 18:34:00 GMT 2006
--- "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 
> >  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
> on X. Maybe this will be less important now, with the modular X, but I
> 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
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.
More information about the Cygwin-apps