This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: HEADS-UP: Modular X11 (ALL maintainers, please read)
- From: "James R. Phillips" <antiskid56-cygwin at yahoo dot com>
- To: "cygwin-apps at cygwin dot com" <cygwin-apps at cygwin dot com>
- Date: Mon, 17 Apr 2006 11:34:21 -0700 (PDT)
- Subject: Re: HEADS-UP: Modular X11 (ALL maintainers, please read)
- Reply-to: 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