GhostScript 8.51

[Rick Stevens]

Mark McCulligh wrote:
> Rick Stevens wrote:
> 
>> Mark McCulligh wrote:
>>
>>> Hi Group,
>>>
>>> I am trying to install GhostScript 8.51 on my RHEL 3 box.  I 
>>> currently have version 7.x on the box installed using the rpm.  I 
>>> cannot find a rpm that will work for GhostScript 8.51. (If someone 
>>> knows of one let me know, PLEASE!)  I am going to try and install it 
>>> by configuring from source.  I was wondering what is the best way to 
>>> go about it. Do I just compile the source and it will update my rpm 
>>> version of GhostScript.  Should I remove the rpm version first? It 
>>> has lots of depends for I don't know if I can uninstall it without 
>>> breaking something.
>>
>>
>>
>> If you are posting a message with a different subject, please post a NEW
>> message.  Do NOT reply to an existing message and simply change the
>> subject.  That's called "thread hijacking" and it's highly frowned upon,
>> Mark.  Since I've never seen a post from you before, we'll let it slide
>> this time.  ;-)
>>
>> However, to answer your question, first be aware of the fact that RH
>> won't support any issues you have with the new Ghostscript.  RH only
>> supports items that come from their up2date servers.
>>
>> Now, how to build it:  You should read any README or INSTALL files that
>> come with the source tarball for dependencies and such and make sure you
>> have those items installed first.
>>
>> Next, the general process for building and installing programs from
>> source is this sequence:
>>
>>     $ cd /package/source/dir
>>     $ ./configure
>>     $ make
>>     $ su
>>     # make install
>>
>> There are usually a number of options you can give to the configure
>> scripts, such as the directory you want it to install into, enabling
>> different options, etc.  "./configure --help" will usually list these
>> options.
>>
>> You should also watch the output of configure fairly carefully.  Look
>> for any errors regarding missing packages, libraries and such.  Fix
>> those before you go to the "make" step.  You want "configure" to run as
>> cleanly as possible.
>>
>> Most packages will default to installing into /usr/local.  This makes
>> it fairly easy to delete if you want to.  Some programs also have a
>> "make uninstall" option (you'd have to look at the Makefile generated
>> by the configure program to see).
>>
>> Should you decide to install it in the normal Red Hat spot by using the
>> "--basedir=" options (thereby overwriting the version from the RPM),
>> make sure you have the original RPM file saved somewhere.  That way, you
>> can reinstall the RPM over the top of the new file by doing:
>>
>>     # rpm -Uvh --force name-of-rpm-file.rpm
>>
>> ----------------------------------------------------------------------
>> - Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
>> - VitalStream, Inc.                       http://www.vitalstream.com -
>> -                                                                    -
>> -                   Never try to outstubborn a cat.                  -
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Redhat-install-list mailing list
>> Redhat-install-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>> To Unsubscribe Go To ABOVE URL or send a message to:
>> redhat-install-list-request at redhat.com
>> Subject: unsubscribe
> 
> 
> Thanks Rick, I didn't mean to "thread hijacking" I will remember that.

No problem.

> When replacing a package that was originally installed using rpm and you 
> upgrade by compiling from source.  Is the rpm version replaced?

No.  rpm depends on its database (/var/lib/rpm/__db.00*).  Installing
from a compiled source tarball does not affect the database, so rpm will
continue to report the old rpm version of the package.  It doesn't know
that a new one was installed.

>                                                                 I know 
> there will be orphan files has the two will most likely install files in 
> different locations.  But me fear is that both Ghostscript 7 and 
> Ghostscript 8 are running at the same time and will conflict with each 
> other down the road.

Well, if you install in /usr/local, you can have both.  The trick is to
see which one would get invoked when run when you enter "ghostscript".
That's governed by your "PATH" environment variable ("echo $PATH" to
see what it is now).  If you don't specify a path to the executable, the
system walks down the path looking for a match.  The first one it finds
is the one it runs.  You can change the path order by editing various
files in /etc ("/etc/profile", "/etc/bashrc", etc.) and your local
"~/.bashrc" files.

> PS Yes I know RH will not support the newer version of Ghostscript, but 
> a client needs the newer version.

No problem.  I just wanted to make sure you were aware of that issue.
Some people don't realize it and get, uhm, shall we say "annoyed" at Red
Hat. :-p
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-           "I understand Windows 2000 has a Y2K problem."           -
----------------------------------------------------------------------