Re: has anyone gotten nosh to build on Void Linux?

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sun, 1 Jul 2018 18:18:22 -0300

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.
Received on Sun Jul 01 2018 - 21:18:22 UTC