2018-06-30 21:27 GMT-03:00 Chris Brannon: > > Sorry, I didn't have time to reply, but I made a good deal of progress > earlier today, after writing to the list.
Great! > I also needed to fine libtinfo, because > Void doesn't have it. Void could probably have libtinfo provided by > their curses package with a fairly straightforward change. > I figured out how to get libtinfo from ncurses by looking at the Arch > PKGBUILD for ncurses. Depending on how ncurses is built, libtinfo isn't actually needed. ncurses' build system makes a libncurses library that may come in two variants: one that only has the narrow character functions, and another that has both the narrow character and the wide character functions. You get the latter if ncurses' 'configure' script is passed an --enable-widec option, and this also renames the library as libncursesw. This means that libncursesw is essentialy libncurses with more code, so it has everything libncurses has. ncurses' build system can also split parts of libncurses out to separate libraries, one of them being libtinfo, "the termlib library". You get a libtinfo if the 'configure' script is passed a --with-termlib option. This means that without that option, libncurses / libncursesw has everything libtinfo has. Debian chooses to build libtinfo, Gentoo does not unless requested by the administrator with the 'tinfo' USE flag, and Void seems to choose to not build it. If that is the case, however, instead of trying to produce a libtinfo somehow, you could just patch nosh's source/system-control.do and source/system-manager.do scripts (they are shell scripts): change the lines that do the tinfo=-ltinfo assignment with tinfo=-lncurses. I do something like this on Gentoo. > > would also help to know what the ID and VERSION_ID fields of Void's > > /etc/os-release look like. I believe the former is 'void', and the > > latter is absent, correct? > > That's right. Good. There are some .do scripts that parse /etc/os-release and have a case ... esac command that tests for different values of those fields. They are used by redo to build some service bundle directories (nosh's native format of a 'service definition') and components of the configuration import subsystem, and are detailed in the aforementioned "Packages and Ports" chapter of the nosh Guide. If you can figure out what should go in new void:*) lines, maybe that might get included upstream :) Cheers, G.