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

Igor Peshansky pechtcha@cs.nyu.edu
Mon Apr 17 19:42:00 GMT 2006

On Mon, 17 Apr 2006, James R. Phillips wrote:

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

X is part of the base Debian install.  It is not part of the base Cygwin

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

Unless the set of X libraries is *really* small, it would make sense to
have a non-X version of ghostscript.

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

You're right, the alternatives system will not work.  You could try to
have a postinstall script that retargets a symlink -- have ghostscript-nox
postinstall only create the symlink if not present, but let
ghostscript-x11 retarget the symlink if it points to the nox version.
Besides, I'm sure many files could be shared betwee the two installations.
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

More information about the Cygwin-apps mailing list