Invalid symnlink of libncurses.so.5 and libtinfo.so.5

[iddev5]

When running nano from overlay bundles, it complaints about libncurses.so.5 and libtinfo.so.5 being non-existent. This is because in ncurses's build file, they are related to libncursesw.so.5 and libtinfow.so.5 respectively which do not exists(current version of ncurses is 6.1 not 5.x)

Solution:
Changing ncurses/02_build.sh: line 55-59 from

ln -s libncursesw.so.5 libncurses.so.5
ln -s libncurses.so.5 libncurses.so
ln -s libtinfow.so.5 libtinfo.so.5
ln -s libtinfo.so.5 libtinfo.so

to

ln -s libncursesw.so.6.1 libncurses.so.5
ln -s libncurses.so.5 libncurses.so
ln -s libtinfow.so.6.1 libtinfo.so.5
ln -s libtinfo.so.5 libtinfo.so

Though I haven't looked into nano's build script for a way to make it directly use ncurses 6.1 instead of 5.x, which is probably another way to solve this issue.
On a side note, isn't it tedious to manually manage versions, why not have something in .config?

[ivandavidov]

Good observation. I'm open for suggestions how to permanently fix this.

[iddev5]

After thinking about this a bit, I think there is no simple, practical way to solve this problem. Afterall dependency management is a complicated issue and its not feasible to create too complex systems for this kind of project, right?

Anyways, in my local repo, I upgraded nano in the hopes that it will not depend on .5.x set of so files and instead use ncurses 6. It didn't, or probably I do not understand how it works... I will look more into it later(maybe some configure options)

A side question: is hdd.img and OVERLAY_LOCATION=iso meant to be mutually exclusive(Sorry for going off-topic but I do not wanna spam this repo with issue within two days haha)

[ivandavidov]

hdd.img is just a tool that I designed in order to test how the overlay system works.

MLL scans for all available filesystems in alphabetical order and merges the overlay content from the first one with proper overlay structure. In that sense the two options are mutually exclusive, because if there is a hard disk attached, then sda (hard disk) comes before sr0 (CD/DVD ROM device) and MLL uses it, completely ignoring the overlay structure on the ISO image. It's a kind of side effect of how MLL handles the overlay structure. Of course, this process could be enhanced to take into account not just one, but all possible filesystems with proper overlay structure (though it would require a lot of additional work).

[iddev5]

Thanks for the explanation, it makes a lot of sense now. Again sorry for taking it off-topic.