The following is an overview of development projects that need to be done before the operating system can be considered ready for production use.
Currently, service init scripts are provided by the monolithic initscripts binary package. These init scripts are executed in the lexicographic order of the symbolic links matching /etc/rc.d/S* that target them. The names of these symbolic links are currently hardcoded in the build makefile of the basefiles source package. This monolithic packaging and hardcoding of link names is a temporary and poor technical solution that doesn't scale with the number and selection of services that can be installed on a system. Init scripts should instead be provided by the packages that provide the relevant system services. The order in which init scripts are executed should be determined by dynamic boot sequencing based on inter-service dependency metadata.
This boot sequencing can be done when the system boots or after a new system service is installed. For reference, NetBSD uses a program called "rcorder" to determine a boot sequence at boot time. Many GNU/Linux distributions follow (to some degree) the Linux Standard Base (LSB) specification, which defines "Comment Conventions" for dependency metadata and a method for installing sequentially-named symbolic links. Conforming implementations perform boot sequencing at the time of service installation. Because boot sequencing at boot time can slow down system booting, it is better to perform boot sequencing at install time.
Thus, generally speaking, the solution to be adopted in this system is to make packages that provide system services also include the necessary init scripts (installed in /etc/init.d), to include inter-service dependency metadata in init scripts, and to use a tool at the time of service package installation to generate sequentially-named symoblic links in /etc/rc.d.
An obvious boot sequencing tool is "insserv" maintained by Werner Fink and used by Debian and openSUSE. However, this C program (in compliance with the LSB) assumes the use of runlevels. This operating system uses the init daemon of BusyBox, which doesn't support runlevels. Therefore, we'll need to either modify insserv to work without runlevels or write our own tool for installing symbolic links to init scripts.
Additionally, we need to decide how completely we'll conform, if at all, with the LSB in this area.
Hopefully, this can get done by September 2012.
Multiarch refers to the ability to install and use packages built for non-native architectures. It is currently being documented and implemented in Debian and Ubuntu. Multiarch is useful for this distribution because it makes cross compiling easy (see "Package Cross Building Tool" and "Multiarch Cross Toolchain Packages" below).
Simply speaking, there are six aspects of a multiarch implementation:
To accomodate simultaneous installation of shared libraries built for different architectures, library paths are suffixed with a directory name that identifies a particular architecture. For this distribution, that directory name will be the name of the binary architecture; for example, library paths for the cortexa8-linux-eglibc architecture will be /lib/cortexa8-linux-eglibc and /usr/lib/cortexa8-linux-eglibc.
The toolchain (especially the dynamic linker) needs to be configured to use these library paths.
Multi-Arch Control FieldA Multi-Arch control field specifies how a package can satisfy dependencies of other packages. A value of same means that a package can only satisfy dependencies of packages built for the architecture for which it was built. This is useful for shared libraries, which can only be dynamically linked against binary objects built for the same architecture. A value of foreign means that a package can satisfy dependencies of packages built for any architecture. This is useful for utility programs, which can be used by software built for any architecture.
The package manager (opkg in our case) and package building tools (specifically oh-checkbuilddeps of opkhelper) must be able to understand and use this field in resolving package dependencies.
Control fields like Depends are extended to support an architecture specification of either any or same, allowing a package to specify whether or not it needs a package of the same architecture. The dependent package has a Multi-Arch field with value allowed.
The package manager and package building tools must be able to understand and use this architecture syntax in relationship fields.
Architecture: allDependence on packages installable and usable on any architecture (especially considering opkg's ability to install packages of multiple architectures) must be researched.
Library packages provide files outside of system library paths, such as configuration and package documentation files. A solution must be designed to allow a package built for one architecture to be co-installable with the same package built for a different architecture (or to determine if they are co-installable at all).
The package manager must be able to install packages built for multiple architectures (the whole point of multiarch). Fortunately for us, opkg already handles this. The arch option in opkg.conf allows the user to specify architectures for which packages can be installed.
In summary, there is much design work to be done, opkg and opkhelper must be modified to support multiarch, and certain packages will need to be built to handle multiarch library paths. Of course Debian is a great reference implementation, but there still remains much original work to be done.
A tool similar to debootstrap of Debian needs to be written to bootstrap the installation of a basic system. It can be used for building packages (see "Package Cross Building Tool" below) or installing the operating system on hardware targets.
Basically, the tool would fetch from the package archive the index of packages, determine which packages need to be installed, download each package, and unpack each package. Since the package manager may not be available, the tool must handle dependency resolution and package unpacking on its own.
To be determined is how the "second stage" of the installation – the execution of package maintainer scripts (preinst and postinst) to complete the configuration of each package – will be done. At least most of the time, this tool will be used to install packages built for an architecture that differs from the architecture on which the tool is run; therefore utilities used by maintainer scripts may not be executable. In this situation, debootstrap leaves behind a copy of itself in the installed system to be executed on the target architecture. Such a solution might not work for this tool, because nothing can be executed on the target architecture until the installed system is booted, and the installed system shouldn't be booted until after the packages are configured.
We can't use debootstrap, since the formats of our binary packages and package archives differ slightly from those of Debian. But we can model our tool after debootstrap or even just fork debootstrap.
If written portably (i.e. in conformance with POSIX.1), this tool could be used to make base system images on any UNIX-like operating system with an implementation of tar. On any operating system that also has a chroot program, this tool can be used with the package cross building tool described below to build packages for this distribution. Therefore, these tools can be thought of as a "Software Development Kit" ("SDK") for the distribution, usable on any capable development system.
Hopefully, this tool can be done by October 2012.
A tool similar to pbuilder and sbuild of Debian needs to be written to build packages within a chroot environment containing a base system installed by the installation bootstrap tool. It needs to support cross building of packages using multiarch cross toolchains.
Needed are packages of toolchain components (e.g. GCC and EGLIBC) that use multiarch library paths.
There is currently a Google Summer of Code 2012 project to develop such packages for Debian.
There are always more source packages to be made. Software that should be packaged soon includes:
Dropbear is a small SSH server and client, in many ways compatible with OpenSSH.
In addition to the basic packaging work, there is work to be done on a service script (just a simple shell script in /etc/init.d) and postinst and postrm maintainer scripts to generate and delete the SSH host key pair.
GNU Autoconf generates configure scripts that are used to configure software packages for building.
GNU Automake generates Makefile.in files that are used to build software packages.
GNU M4 is a macro processor, notably used by GNU Autoconf.
Perl 5 is a language interpreter, especially popular in systems administration and software build and installation systems.
Unmodified Perl 5 source is impossible to cross build without executing software on the host system (in GNU Autoconf terms, the system for which the package is built). See this mailing list thread for more information. We will need to modify Perl's build system a bit before we can build a package.
GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. It is used by GCC.
MPFR is a C library for multiple-precision floating-point computations with correct rounding.
MPC is a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result.
GNU Binutils is a collection of binary utilities, including a linker and assembler.
Binutils and GCC are part of the multiarch cross toolchain project.
GCC is an optimizing compiler with frontends and libraries for a wide range of languages.
Binutils and GCC are part of the multiarch cross toolchain project.
GNU Make is a tool that automatically builds software packages.
U-Boot is a bootloader used on many embedded computers, including the BeagleBoard-xM.
opkg includes and is statically linked with a copy of libbb, BusyBox's helper library. Of course, BusyBox is also linked against its own copy of libbb. This is a bad idea in general, since duplicated code makes maintenance more difficult and is often subject to bit rot (resulting in long-standing bugs and security problems). It's an even larger problem (no pun intended) in embedded systems, where saving space is important.
libbb can be built as a shared library by setting the CONFIG_BUILD_LIBBUSYBOX option to y in BusyBox's configuration. So, we can make libbusybox.N and libbusybox.N-dev binary packages that provide this shared library and its header files, modify opkg to dynamically link against this library (instead of statically linking against its own copy), and add dependency information to the opkg source package and its binary packages.
The copy of libbb in opkg hasn't been updated from its upstream source since at least 2008, when opkg development began from the old ipkg sources. Three months later, an attempt was made by Koen Kooi to update the copy of libbb, but it was determined that BusyBox had changed significantly since the code was added to ipkg. Things have most likely gotten much worse in the more than three years since then.
To make matters slightly worse, many of the libbb files have been patched in opkg. Any files in /trunk/libbb newer than revision 3 have opkg modifications.
Build-Depends and Depends fields to the opkg source package.busybox source package, and forward it upstream to BusyBox.