Very Computer

OK, in my never-ending holy quest to get Linux up and running to its full
power, I've got another little quandary to work out: I have an Epson Stylus
Color 500 printer, and the version of GS installed with RedHat (3.33) doesn't
offer support for it. No problem, I'd just go install the updated 5.10
version. No such luck. I've got the libpng, jpeg-6a, and zlib libraries in the
proper place, and compilation goes fairly well until, several minutes into the
project, I get dumped out with an Error 1 message: Cannot find file -lXt. I'm
a bit confused, and ready to pull my hair out... If anyone has any
suggestions, I'd truly appreciate it. E-mail me if possible, but anything at
all would help.

--

 "Long live all of us crazy soldiers     | "I'd like to thank Microsoft
  Who were born under calico skies       |  for making companies put that
  May we never be called to handle       |  'Made for Windows 95' logo on
  All the weapons of war we despise.     |  their products. That way
       - Paul McCartney, "Calico Skies"  |  know what not to buy."

   2500 posts and Belthasar's Post of Reason to alt.games.final-fantasy

-----------------------------------------------------------------------

Laboratoire de Modelisation et Calcul  | Tel: +33 4 76 51 44 23
BP 53, 38041 Grenoble cedex (France)   | Fax: +33 4 76 63 12 63
-----------------------------------------------------------------------

Your problem is clearly described in the enclosed docs. Read install.txt and
make.txt. Before you start compilation, you've to edit some mak-files.

Have a nice day and success.

Dieter Rohlfing

Quote:>There is a precompiled ghostscript-5.10 rpm at the redhat contrib
>directory (mustang) or a mirror site. You may try it.

        rpm -U ghostscript-5.10-2.i386.rpm

(I needed it for use with latex2html, which supposedly requires gs 4.03
or later if you want your text properly antialiased.)

The result:

% gs
Segmentation fault

An strace showed the problem happening very early on, right after getpid,
before doing any ghostscript-related stuff.  No idea what's going on
there.

Getting gs 3.33 reinstalled was an uphill battle: when I tried
to rpm -e ghostscript-5.10-2.i386.rpm, rpm complained that it wasn't
installed.  But then when I tried to install gs 3.33 it complained that it
couldn't install 3.33 on top of 5.10.  After various combinations all
failed, I finally gave up in disgust and did the usual

        rpm -i --replacefiles  --replacepkgs

To digress even further (out of sheer pent-up disgust with rpm), every
time I use rpm I go through this routine, like Charlie Brown kicking
the football, in the faint hope that *one* day rpm will actually
fulfill RedHat's promise on its web site of

Quote:>Seamlessly binding together the cooperatively developed Linux, the Red
>Hat Package Manager, RPM, makes upgrading and maintaining your Linux
>system painless and worry-free. The RPM packaging system eliminates
>guess work and prevents major system failures when installing,
>uninstalling, and upgrading software packages.

Sorry about the flame, I'm just temporarily annoyed about the really
big time sink that getting latex2html and ghostscript to work together
under RedHat 5.0 is turning out to be.

Vaughan Pratt

Quote:>Someone should talk to RedHat about truth in advertising.  The rpm
>concept is wishful thinking on the same scale as the antigravity belt.
>In two years of trying to use it the only times rpm has worked smoothly
>for me are in from-scratch installations, and with
>--replacepkgs --replacefiles.  Rpm is a well-intentioned mistake.

>Sorry about the flame, I'm just temporarily annoyed about the really
>big time sink that getting latex2html and ghostscript to work together
>under RedHat 5.0 is turning out to be.

One should be able to "reverse install" an rpm, by installing the files
manually then verifying against a "skeleton rpm" that just contains the
manifest and checksums, and if it passes, considering the new RPM installed.  

One should be able to force the entry to be added to the rpm database if it
fails verification or if one doesn't care to verify at all.  If I hand-upgrade
my kernel and don't use an rpm, I want to be able to make the rpm database
reflect the new version.  Otherwise I'll have to use --nodeps down the road,
or install manually, causing a cascade failure effect.

the rpm command could use an "unpack" option that treats it like a tarball and
just extracts it with a relative path, not a rooted one.  no rpm2cpio and
using chroot all that whatnot.  This would go well with a notion of a "partial
install".  Maybe some kind of "sub package" system.

Some fluff that would be nice:

rpm's over http
version check for packages, like perl's CPAN::
come to think of it, something like CPAN:: in general
"push" installs with rdist.