Forum OpenACS Q&A: Response to OACS4.x install, make for nsxml fails

Collapse
6: Response to OACS4.x install, make for nsxml fails (response to 1)
Posted by Jonathan Marsden on 01/31/02 01:07 AM
Torben,

If you are creating OpenACS4 install info for SuSe users, using RPMs is probably the best way forward long term, since SuSe is an RPM-based distribution. So minimizing install pain for 'real' OpenACS4/SuSe users would mean using an installation approach they are likely to be familiar with already -- RPMs.

This is doubly so if you don't have a lot of experience with autoconf and make, which is my suspicion (from the posts you have made). There are only so many hours in a day -- why not use them on OpenACS stuff, instead of on arcana relating to autoconf and make and compiling etc.

I'm not really sure about the benefit or wisdom of untarring libxml2 underneath nsxml.  These are two very different things.  You need libxml2 installed in order to compile nsxml, but you don't need to unpack it in the nsxml source directory (well, at least, I don't, on Red Hat 7.1). libxml2 is not a part of nsxml, so why unpack it there?

There is a new issue with libxml2-devel which might be what you are running into.  The RPMs from xmlsoft now put the header files under
/usr/include/libxml2/libxml instead of
/usr/include/libxml

I suspect this is a mistake, though I have not contacted xmlsoft to verify that.  The fix for our purposes is pretty trivial: hack the nsxml Makefile to add -I/usr/include/libxml2 to CFLAGS.

For sure, installing libxml2 and libxml2-devel RPMs as Vinod suggests
is likely to help you a lot (or installing libxml2 from tarball sources if you insist and want another challenge).  BTW, if you had tried installing my aolserver-nsxml RPM it would have let you know it needed libxml2 -- in other words, RPM dependency checking could have helped you towards your goal.

If (as Vinod and I both suggest) you will agree to use RPMs for libxml2 and libxslt, my question is, why not be consistent, and use RPMs for the other necessary components (including AolServer and its nsxml module) too?  And then... well, why not stay consistent, and use an RPM for OpenACS4 itself too 😊 😊

Ultimately a consistent and simple installation method is what will
probably help 'real' SuSe users to get started with OpenACS4. Compiling and installing everything from tarballed sources is quite possibly fun for some people, and might be useful as a learning experience for you personally, but it may well not be the easist approach to OpenACS4 installation for SuSe users in the long term.

Downloading 10 or so RPMs and typing

  rpm -Uvh *rpm

seems a lot easier than what you are currently going through ... doesn't it?  And that is what I do to install
PG/AolServer/OpenACS4.  OpenACS4 up and running in under 3 minutes
(plus download time of course).

I confess I am currently slightly confused by the multiple people apparently doing (or wanting to do?) installation documentation related to OpenACS4, so for now I am just building RPMs once in a while, and waiting for a beta announcement; once we have 'official' install docs included in a release and in CVS, I can look at submitting patches to them for RPM users, as I did for OpenACS 3.2.5.  Or, I'd welcome someone who is a real doc writer looking at how best to deal with the documentation needs of RPM as well as tarball based installs!

My current Aolserver 3.3.1-1+ad13 RPM set can fail to install OpenACS4 on Red Hat 7.1 under some circumstances... a new set 3.3.1-2+ad13 should be appearing very soon to fix that... it works here so far!  Whether it works on SuSe or any other Linux distribution I can't say... I'd love to hear what happens when people try this, whether it works for them, or not!