TMSR OS is being made to primarily serve its implicit clients : TRB, a replacement ircd, A-M-P, Eulora, TMSR-PGP and a collection of coreutils. Every piece of code on the system shall be a vpatch in the TMSR OS vtree.
This is a very early working document intended to start the process of enumerating the complete set of software required for TMSR OS. It's known to be incomplete on some levels and there are items on the first draft that will be struck out, but it's unclear to me at present whether they should be struck off immediately or over time. The idea is to drill down on what is actually needed to support the clients and stabilize the list over time through discussion.
The system first needs to be built, which will initially take place on some non-TMSR OS system, e.g. Gales Linux, where the TMSR OS vpatches are installed, pressed and the result is compiled and packaged into installable media for the target machine. For the build process to be, I think an adaptation of Gales' cross-compilation approach has merit.
For this document, I used Gales Linux as a starting point since, though it doesn't use V to control the sources, its aims are similar to TMSR OS. Here's the list :
- V
- Ada
- Kernel : Linux 2.6.32
- C compiler : GCC 4.4.7, 4.7.4 and 4.9.4 are up for consideration, 4.7.4 can reportedly be built with tcc
- C library : musl static for the base C library. It's unclear at present if graphics stack can be statically built, may need to be structured to extend system to support dynamic linking for deployments that use graphics.
- The Real Bitcoin
- openssl-1.0.1g
- db-4.8.30
- boost-1.52.0
- Gales Bitcoin Wallet
- Gales Scheme
- Python
- SQLite
- ircd : to be determined
- yrc is an IRC client that was was genesis'd. Python based for now.
- A-M-P
- Apache 2.4.16
- MySQL 5.5.60
- PHP 4.4.8 or 5.6
- TMSR-PGP
- Coreutils :
- Busybox (Gales uses 1.24.2)
- Items potentially preferred to what busybox provides, needs to be researched and discussed:
- Gales init vs bb's init
- daemontools vs bb's runit
- MAKEDEV vs bb's mdev
- Gales pdksh vs bb's ash or perhaps something else
- binutils (Gales uses 2.24)
- curl, Busybox provides wget, but Eulora appears to require curl
- e2fsprogs (Gales uses 1.43.4)
- gmp (Gales uses 6.0.0)
- make (3.80+ for gcc 4.7.4, Gales uses 4.2.1)
- manpages, man-pages-posix, mandoc
- mpc (Gales uses 1.0.3)
- mpfr (Gales uses 3.1.5
- acpica, required by Coreboot
- xc3sprog, JTAG hardware debug
- Assorted Build Dependencies (i)
- autoconf, required by Gales builds of bc, bison, flex, php56, Python, readline
- automake, required by Gales builds of bc, bison, flex
- bc, required by Linux
- bison, required by acpica
- bzip2, required by Gales Python build
- flex, required by acpica
- m4, required by autoconf
- ncurses, required by : BusyBox, Linux and Coreboot config, Gales build of Python, readline
- perl, required by automake and autoconf
- readline, required by : Gales builds of Python and SQLite
- zlib, required by Gales Python and SQLite builds and Crystal Space
- Eulora client dependencies provided by Diana Coman (archived). Note X11 is required, but isn't included on first iteration.
- Crystal Space
- Cal3d
- Cg - NVIDIA Cg Toolkit
- mesa-libGL-devel, needed for X11, opengl, cg and linux-joystick
- lib3ds (noted as possibly not needed ; I'm unsure where to find sources as google 404s)
- libvorbis
- cairo, has deps (devel mainly): freetype, libpng, libxrender, pixman, fontconfig
- bullet
- speex
- wxBase, noted to have NO effect by itself
- theoradec
- gtk, wxwidgets, noted to have 16 dependencies!
- openal
- libjpeg-turbo, note : and it is NEEDED because most textures in examples and walktest are .jpg
- alsa note : and it is NEEDED for sound apparently, at least for walktest
- BIOS :
- Coreboot
- SeaBIOS
- ich9deblob
- flashrom, requires libpci-access, libusb, libusb-compat, libftdi, which requires cmake
- Bootloader : open question
- autoconf and automake are two examples of dependencies that ought to be cut out. The question is then, when ? Should they be cut out from the beginning or are they tolerable to start and we'll cut out as we go ? Though I've de-autoconf'd packages before, I don't know how hard it will be for these, but I lean towards the former. Rip them out of the ~6 build systems they're present and no autoconf, automake, perl or m4 needed. [^]