[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: RedHat 7.3 and stata
> Maybe it is due to my incapacities in Linux, but I just did a clean
> install and update of RedHat 7.3 last week. I did not explicitly remove
> libncurses.so.4 (but maybe the RedHat update did without my knowledge -
> ie. the problem I pointed out). I think this is supported by the following:
> # rpm --list -q ncurses-5.2-26 | grep libncurses.so.4
> # rpm --list -q ncurses-5.2-26 | grep libncurses
In my three installations of RedHat 7.3, the libncurses 4 library was
included. Perhaps this was because I chose a "Custom" installation method and
installed all of the development tools associated with the RedHat 7.3
distribution. Guessing at the installation method that Henrik used, but if
the older library was not installed with the newer one, that leads me to
beleive that he chose a "Workstation" class installation.
Also to note, if I perform the rpm query as Henrik demonstrates above, my
"Custom" installations only list the libncurses 5 library.
> To me this implies that the file libncurses.so.4 is not part of
> ncurses-5.2-26 package(?) Now it might have worked, as Pete suggested,
> to just create a symbolic link to libncurses.so, but I do think this is
> quite beyond what an ordinary user should be asked to do, and I would
> still consider it a problem for either Stata or RedHat.
> Further, I am wondering what the motivation for providing a specific
> package for backwards compatibility (ncurses4-5.0-5.i386.rpm) could be,
> if this backwards compatibility was also present in ncurses-5.2-26?
Stata Corporation is trapped in situations like this. While it would be nice
to ship Stata or X-Stata compiled on a machine with the most up-to-date
libraries, that can also cause problems that require more effort to repair
than making the symbolic link. Using the libncurses example, if we were to
distribute a compile that linked with the version 5 library, we end up forcing
all of the version 4 library users to download and install the new package.
And while the argument could be made to have the users make a symbolic link
from the requested library (newer) to the exising one (older), that is often
not a viable solution since libraries are often "backwards" compatible, but
far less likely to be "forwards" compatible.
4905 Lakeway Drive
College Station, TX 77845
* For searches and help try: