[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 9 12:40:51 2001 
Subject:Installing poplog: some bugs and some thoughts 
From:ug55aes 
Volume-ID:1010309.01 

I've just been re-installing Poplog after getting a new system (I'm now
running Debian). I've forgotten most of what I used to know about
Poplog after not using it for too long, so I'm in a good position to 
simulate a newbie...

When I was doing the actual download and install, a few of things
cropped up in my mind:

1) linux1553.tar.gz vs. linuxmotif1553.tar.gz caused me some problems:
they're both large downloads, and for some reason poplog isn't
recognising the lesstif on my system (more on that later).  If I were 
getting this stuff from an expensive dial-up line, a mistake could be 
quite costly.
2) What install file do I run?  INSTALL_LIKE_BHAM, INSTALL_MOTIF, 
or INSTALL_NOMOTIF?  They're all very prominent, and INSTALL.TXT
seems to disagree with README about which you should run.
3) The installation had a general tendency to do things without checking
if they'd work, then just fail if they didn't.

What I'm working towards is: is it possible to have a small shell script 
which does overall handling of the installation that:

1) Checks that you're running Linux (`grep Linux /proc/version`), just
   in case.
2) Checks whether the relevant mo/lesstif files are present.
   a) If so, looks for linuxmotif1553.tar.gz in the current directory
   b) If not, looks for linux1553.tar.gz in the current directory.
3) If it fails to find the relevant file or popcd.tar, gives out the
   FTP address to get hold of the missing file(s).
4) If it succeeds in finding the file, unpacks linux*1553.tar.gz, cd's
   to /usr/local/poplog, and execs ./INSTALL_(NO)MOTIF > install.log

If you could just point downloaders to a small script like that, it could 
go a long way to helping with installation problems.


Before I leave the actual installation section, I should say that as
part of the effort to standardise filesystem layouts across Linux
systems, /usr/local/ is being set aside for user-stuff, not maintained by 
the system itself.  I guess that means that /usr/local is the right place
for Poplog, but it should probably go somewhere else if anyone does
manage to package it.



Next: when I was last using Poplog, I noticed a number of dodgey symlinks.  
So, once I'd finished installing, I did the following, from 
/usr/local/poplog:

# grep -r test . > /dev/null
grep: ./local/com/login.scripts/user.standard: No such file or directory
grep: ./local/com/login.scripts/user.poplog: No such file or directory
grep: ./local/lib/vision.p: No such file or directory
grep: ./local/lib/popvision.p: No such file or directory
grep: ./local/lib/sunrasterfile.p: No such file or directory
grep: ./local/lib/poprulebase.p: No such file or directory
grep: ./local/lib/newpopvision.p: No such file or directory
grep: ./local/lib/sim_agent.p: No such file or directory
grep: ./local/auto/ved_setwindow.p: No such file or directory
grep: ./local/saved/teach/latex: No such file or directory
grep: ./local/saved/teach/latex.tex: No such file or directory
grep: ./v15.53/pop/local/com/login.scripts/user.standard: No such file
or directory
grep: ./v15.53/pop/local/com/login.scripts/user.poplog: No such file or
directory
grep: ./v15.53/pop/local/lib/vision.p: No such file or directory
grep: ./v15.53/pop/local/lib/popvision.p: No such file or directory
grep: ./v15.53/pop/local/lib/sunrasterfile.p: No such file or directory
grep: ./v15.53/pop/local/lib/poprulebase.p: No such file or directory
grep: ./v15.53/pop/local/lib/newpopvision.p: No such file or directory
grep: ./v15.53/pop/local/lib/sim_agent.p: No such file or directory
grep: ./v15.53/pop/local/auto/ved_setwindow.p: No such file or directory
grep: ./v15.53/pop/local/saved/teach/latex: No such file or directory
grep: ./v15.53/pop/local/saved/teach/latex.tex: No such file or
directory
grep: ./v15.53/v15.53: Too many levels of symbolic links
(repetitions for current.poplog snipped to save space).

Can someone look into/fix these?  As an example,
local/com/login.scripts/user.standard is a symlink to
/bham/common/system/templates/user.standard - oops :)



Next again: why not put the files in linuxterm.tar.gz in with
linux1553.tar.gz?  Admittedly I'm biased, but ved just throws up on my
console without them.  Many newbies wouldn't know to install
linuxterm.tar.gz, and some would assume they'd done something wrong.




Finally: Poplog has trouble with some libraries.  I seem to recall some
of them had to do with being compiled on an RH6.0 system, which has a
number of eccentricities.  Given that downloading Red Hat 7.0 (or just
about any other distribution, for that matter) is free, it'd probably be
a good idea to get a more recent version - RH6.0 is a couple of years
old now, which is an eternity in Linux time.

I remember from last time having to do:

ln -s /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libX11.so
ln -s /usr/X11R6/lib/libXt.so.6 /usr/X11R6/lib/libXt.so

Which I had to do again on this system.  I seem to remember this is an RH6 
bug, so is it possible to get Poplog to link against the real files?

Also, Poplog requires libtermcap.  It's the only package on my system
which does.  According to my termcap-compat package, moving over
to ncurses just requires you to "replace the '-ltermcap' with 
'-lncurses' in the makefile".  Can you make this change - libtermcap
probably won't be maintained forever.

And, I said, I've got lesstif installed on my system at the
moment (Debian is relatively strict about licensing matters - the
free-ish Motif is probably still frowned on, for example).   The motif
installation looks for (I think) libXm.so.2, and found nothing.  
Will making a symlink libXm.so.2 do the trick here?   If so, a recompile 
will probably fix this too.



Right, I'm off to make life hard for some other people for a while :)
	- Andrew