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
install.
> 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.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED]
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"
