Re: [GeneX-dev] Installation experience..

[<ja...@op...>]

"Harry Mangalam" <man...@ho...> writes:

>   "Michael Pear" <mic...@ho...> writes:
>   #
>   # Here is some feedback regarding pre6...it is looking really
>   # good. 

Oh, I'm blushing ;-)

Make sure Lonny and Greg hear that, don't want them thinking I've
gotten lazy ...

>   # There is only one problem that really should be addressed in
>   # your script: make sure that when an executable is supplied that
>   # it REALLY is an executable file instead of a directory.

Nuts, thought I'd settled that one...

>   # ****It is possible to enter a directory name as a substitute for an
>   # executable in the section asking program names, and it is particularly
>   # sticky once this is done. After installing dtd2html in my local
>   # directory not in the path, I accidentally entered /var/genex/local/bin
>   # without pointing all the way to the executable. After that, the only
>   # way I could recover was to edit the Bio/Genex/Config.pm file directly.
>   # Even when I ask to answer the installation questions again, it appears
>   # that it is checking the location of the executables rather than asking,
>   # so it keeps finding the directory. I think this is the most critical
>   # issue left in the installation, for those of us prone to making
>   # mistakes.
> 
> OK - Adding a check for -f and -x would cure this, no?

This is two problems. First I think we want -x && !-d, so that it's
executable but not a directory (I don't know how -f handles funny
files). 

The other problem is that if you re-run the installer after your
installation, and tell it *not* to auto-accept what's in Config.pm,
it doesn't stop on any of the applications...

>   # ***Perl modules are still one of the  most difficult to get right. I
>   # suggest you recommend XML::Parser and XML::DOM to make sure that parser
>   # works right before other tests. The problem with the XQL tests throws 
>   # a wrinkle in because those problems are acceptable, but ones with the
>   # XML:Parser for example aren't. Harry noted that Class::ObjectTemplate
>   # isn't brought in automagically through dependency when installing
>   # Class::ObjectTemplate::DB, so you need to make those separate.

The Class::ObjectTemplate was my fault. I hoped CPAN would calculate
the dependancy automagically, and I didn't test it (I already have
them both installed :-( 

I'm happy to add XML::Parser first. What is the failed test there?

> And we should still automate this as much as possible.  

Harry and I talked about this, and I think it is problematic for us to
automate cpan. Automation works fine once CPAN is configured, but if
they haven't preconfigured CPAN, the interactive mode sets in to
select a CPAN site...

>   # **Rcluster queue_master gets mentioned, but I didn't need to start it
>   # before to get Rcluster to work....why not? ***Also, what happens on
>   # system reboot? 
> 
> Jason remedied this but it still needs to be added to a genex init script,
> which DOES need to be installed as root in /etc/[rc.d]/init.d and
> symlinked into the appro startup.  Because the different Linux distro's
> put their scripts in different places, we could try to detect which distro
> (I think Jason already added this code) and put it in the appro place (or
> we could just write the script and have root install it where they want). 
> The script will fail on Solaris unless we do some more testing, I
> think. 

Good point. We need to put together a genex init script. queuemaster
is the only one right now, but there are likely to be others.

>   # **Installation itself completing  with no errors depends on dtd2html,
>   # it appears, so you might as well check earlier and kick things out if
>   # the it isn't installed.
> 
> Also, looking at the .subst-cache on genomics I also noted that several
> apps were NOT detected (like sendmail below), but these errors 
> were not caught at runtime or reported by the error reporting at the
> end.

Yes, not locating apps does not trigger an error. We need to indicate
which apps are critical, important, and optional, and based on that,
die() if critical, cause an error if important, or just a warning if
optional. 

>   # *Looks like all doc mods are made to INSTALL....README is out of date
>   # and probably should be removed or changed to refer installer to INSTALL
>   # file.

Hmmm... I just updated README, so it is very current. If you don't
like it could you suggest why? I thought it would be good to have a
general "This is GeneX" document, that talks at a high level, and then
points to INSTALL for the details. Perhaps there are too many install
details in README and they could be moved over.

>   # *Java dependency should be noted for Jpython. Jpythonc is part of
>   # Jpython1.1. Direct installer to look for JPython1.1 rather than
>   # jpythonc. It isn't clear what this is used for on the server, anyways.
>   # Can it be left out? I thought this was more of a development issue for
>   # the dendogram applet. (It will be nice to get rid of this in a future
>   # release, python may be a great scripting language, but you have plenty
>   # of languages to go around at the moment in GeneX!)
> 
> My fault (being Java-ignorant, I thought the class file had to be built for
> each installation as APD has a jpythonc build line in his makefile).  
> This should not be the case for the distro and in fact that line should be
> removed from the rcluster build if we're distibuting the class file (which
> we are, I think..)

This would be great to remove. I assumed that once we had the dendro.jar
we didn't need jpythonc, but I didn't want to change it. Which is why
I left the .jar file in CVS.

Harry if you can remove that I would be sooooooo happy!!!

>   # */usr/sbin/sendmail not detected, although it is a common location
>   # often not in  non-root user's path.
> 
> Yup.  Hmmm.  It's typically on root's PATH, but not on users's....
> we could try a `locate bin/sendmail | wc, check to see if there's more than
> one and then ask which one it was if so...?  I'll play with this

Harry, once upon a time there was a PATH configuration question. It
never gets executed anymore. It seems to auto-accept the PATH. I think
instead of reading in the users PATH, we should set it to a minimal
subset: /bin:/usr/bin:/usr/sbin:/usr/local/bin

And prompt the user for ones we missed. Would this be better, Michael?

>   # *Looking for xcluster in path, but executable by default  from stanford
>   # is cluster in xcluster directory.
> 
> ?? I don't understand this. Could you rephrase?

I think the script is picking up the xcluster directory

>   # *Missed picking up existing tmp file definition in rerun of install.
>   # Most values are picked up and presented as defaults, but tmp file
>   # definition is not for some reason. 
> 
> ?!  Odd.  I'll check.

Nah, it's not that odd, we prompt for a 1,2,3 from the user, we need
to order the list and put the default at the top. I never wrote the
code for it.


Thanks again Michael,
jas.