>
> > If you want to 'rip out'
> > perl my advice would be 1st) install the latest RH RPM, then delete the
> > /usr/bin/perl and /usr/lib/perl5 from your system.
>
> And the man pages or don't subsequent installs check those?
> And /etc/perl.conf or whatever configs it uses?
Nope, perl is totally self-contained, there are no '.conf' files etc.
As for man pages, you CAN fix that if you know where they are and put in the
right settings, but of course perl itself doesn't depend on or care about man
anyway, so its not going to break any functionality, and on top of that if
its the same version of perl then the man pages shouldn't be different anyhow
;o).
>
> > Compile your own perl,
> > making sure to tell it to install itself in the right place,
>
> That's the big trick. Where is the accepted "right place" (ie where
> subsequent package installs will be correctly placed)?
Perl is designed to 'just work'. When you use the CPAN tool or hand invoke the
MakeFile.PL for a package it will ask perl to tell it where perl is
installed, etc. There is actually a module called 'Config.pm' who's function
is to do all of that, so any program can 'use Config;' and learn all about
where perl is installed and how it is configured, right down to the compiler
flags used, version of linker, etc! Do a 'perldoc Config', its says:
The Config module contains all the information that was available to
the "Configure" program at Perl build time (over 900 values).
Shell variables from the config.sh file (written by Configure) are
stored in the readonly-variable %Config, indexed by their names.
etc.
> > otherwise it
> > will end up in /usr/local somewhere.
>
> But /usr/local *is* the right place for foreign utilities. It's
> certainly where I would expect to find Perl. Are you suggesting
> I should put it somewhere else? If so, where is a good place?
Well, perl people have settiled on either /usr/local (so you have
/usr/local/bin/perl and /usr/local/lib/perl5/...) or just plain /usr/bin and
/usr/lib (since at this point Perl is NON OPTIONAL on most systems, try
running Mandrake without it for instance, good luck).
>
> > If it does end up there, you can always
> > symlink /usr/bin/perl to /usr/local/bin/perl and it shouldn't matter.
> > This way all your RPM will THINK perl is there, and indeed a WORKING perl
> > really WILL be there...
>
> Yep, that's what I would normally expect to do if something went looking
> for Perl in /usr/bin and didn't find it.
>
> > Once you do that you will no doubt need to reinstall Apache because your
> > mod_perl won't work anymore, as it is linked to lib_perl.
>
> OK, no problem there.
>
> > You can do a source
> > RPM build of Apache, that SHOULD work,
>
> No, that apparently doesn't work with AxKit (RH9 installs Apache2).
> I used fresh sources of the older version, and mod_perl symbiosed
> with Apache and they rebuilt themselves OK last time.
>
> > just make sure the spec file tells it
> > to build mod_perl (or else you can use apxs to rebuild mod_perl
> > afterwards,
>
> I never got apxs to work, anywhere.
Cheer up, its a cranky thing, I just rebuild Apache from scratch, big deal
;o).
>
> > Honestly, RedHat seems determined to make perl unworkeable and for that
> > reason I've abandoned their distros entirely. They have become a Python
> > shop.
>
> <grin/> No bad thing, IMHO :-)
Python is nice, I just long ago decided to stick with Perl since they are
basically 6 of one and half a dozen of the other. Besides, Python doesn't
have AxKit! :o).
>
> > As far as releases of perl go, stick with 5.8.0 (I have no idea what the
> > subnumbers signify except those are RPM specific, 5.8.0 is a specific
> > release of perl). The only bug with it is that it assumes files are UTF-8
> > in some circumstances, which I guess has been a problem for a few people.
>
> Right. But nice people have posted fixes for this.
>
> > AxKit
> > certainly seems to work well with it. I did add 'encoding="utf8"' to a
> > lot of my XSLT stylesheet XML decilarations to fix some odd characters
> > appearing in output, but I am not sure what caused that, newer perl or
> > other issues.
>
> XML and XSLT I can handle.
>
> > Hope that helps.
>
> Hugely, very many thanks.
>
> ///Peter
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Tod Harter
Giant Electronic Brain
http://www.giantelectronicbrain.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]