Installation on OpenSuSe 42.3 - lcurses vs lncurses

[kevinkrieger]

During installation on OpenSuSe 42.3, I noticed that in order to compile the cdf library (version 36.4 at least), you need to edit the makefile for your particular OS and ENV to use 'lncurses' instead of 'lcurses'.

[egthomas]

@kevinkrieger - do you know if is this related to a change in OpenSuse or that particular CDF version (or both)?

It was only a matter of time before our installation dependency list in the readme became outdated.

[kkotyk]

This happens with any application that links against curses since opensuse is weird like that. The better call is to make a symlink in /usr/lib from ncurses to curses so that all applications that link will work.

[egthomas]

@kevinkrieger , @kkotyk - is this still an issue or can it be closed?

[kkotyk]

reopened @mts299?

[mts299]

Sorry, I am going to reopen this just to get some information from @kevinkrieger for the README file.
@kevinkrieger - Do you remember where you changed lcurses to lncurses?

[kevinkrieger]

It was in the makefile for cdf, and there are sections for each type of OS (linux, powerpc, etc...) I changed it in the section for 'linux'.

[kkotyk]

Its this variable in the makefile that causes the problem on openSUSE

CURSESLIB_linux_gnu=-lcurses

I dont recommend changing this manually though. I might instead recommend making a note to go into /lib and making a symlink from libncurses to libcurses. This is only an openSUSE issue and I've had this error compiling other projects too so I think this solution is a better fix overall.

[mts299]

I have fixed up the documentation. I figured out where the change would have been made.
I documented both methods.

I agree on the fix for all; However, I provided both options just in case they don't want to do a symlink. I did mention that the symlink is recommended.

Calling this closed now!

[asreimer]

Alternatively, just set the CURSESLIB_linux_gnu environment variable manually on openSUSE:

export CURSESLIB_linux_gnu=-lncurses

I haven't tested this, so maybe it doesn't work here, but that's a pretty standard work around when compiling packages.

[mts299]

True, if someone tests it and it works, we can add it in instead of the Manual change.

[asreimer]

The best workaround is the one that is most future-proof and requires the least custom modifications IMO.

I'll be installing RST soon. I really don't want to boot up an OpenSUSE install, but maybe I will just to test this for you.

edit: english is hard.

[mts299]

future-proofing is hard to say in this situation as it is for one library.
However, for future libraries that require lcurses than export or the symlinks are the best options.

@asreimer - Do you want to reopen this issue or do you want to comment on the pull request #141 about your findings?
The pull request might be the best place to mention the alternative options.

[asreimer]

@kkotyk's suggestion to make a symlink is probably the most future proof, but I don't know if it is a good practice for people to recommend that others add symlinks in system folders, hence my environment variable suggestion.

You and @kkotyk know way more about this than I do. I'm just questioning the logic of recommending that users modify system-level stuff if there's a simpler workaround that doesn't require it.

Additionally, I would caution against making OS specific instructions unless absolutely necessary. Do we know that OpenSUSE is the only OS that has this lncurses problem? When I install RST on my fedora machine, we'll know more I guess.

The issue can stay closed. I'll open a new one after my testing.

[egthomas]

@asreimer - we tested against several different Linux distributions last year (hence the instructions in the README file) but obviously couldn't cover all of them. My thought was we should at least cover the major ones (plus macOS) just to make things as simple for our SD colleagues as possible. Luckily we haven't gotten any requests for Windows (yet).

[mts299]

@asreimer - Depending on where things are being set-up they are equivalent at the user level; however, symlinks are more future-proof at the systems level.
Personally, I would like to give both as an option because some people prefer export because it leaves a "paper trail" of what has been changed and just in case they need to change it.
Symlinks can be a bit more mysterious is you don't remember what you linked. At least that is my opinion with working with them. Also, I feel it is up to the user on what they feel most comfortable using.

[asreimer]

@egthomas I've been lurking in the shadows on this repo since it started. You guys have done a ton of really solid work here and I don't think the community appreciates the amount of effort this requires and how much you have put in. I don't mean to imply otherwise. I think you would be hard pressed to find a better documented README for as many different OSes as you guys have here.

Ubuntu and Mint are all Debian derivatives, so if RST installs on one of them, it will probably install on them all. SUSE is the odd one out. I'm guessing this problem will rear it's ugly head on Redhat derivatives like CentOS and Fedora too, hence my question about the problem only being with OpenSUSE.

As for windows...

@mts299 Letting the user decide is a good idea. This has been an interesting discussion, as it appears there is no one "best practice" method for dealing with this kind of issue. Sorry to be such a pain. And on a Monday too...

[egthomas]

@asreimer - no offense taken. It would be really neat if we could expand our travis-ci usage to cover a broader range of linux distros (eg https://blog.travis-ci.com/2017-11-30-testing-ansible-roles-using-docker-on-travis).

[asreimer]

@egthomas As I get my testing done, I'll be sure to report back. Cheers!