Add optimistic completion dates to two projects.

1 files changed, 2 insertions, 0 deletions

diff --git a/dev/todo.html b/dev/todo.html
index 9d7cbbf..6f83bbf 100755
--- a/dev/todo.html
+++ b/dev/todo.html
@@ -8,6 +8,7 @@
 <p>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 <code>/etc/init.d</code>), 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 <code>/etc/rc.d</code>.</p>
 <p>An obvious boot sequencing tool is <a href="http://svn.savannah.nongnu.org/viewvc/insserv/trunk/?root=sysvinit">"insserv"</a> 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 <a href="http://git.busybox.net/busybox/tree/init/init.c?id=3da46c81#n1221">doesn't support runlevels</a>.  Therefore, we'll need to either modify insserv to work without runlevels or write our own tool for installing symbolic links to init scripts.</p>
 <p>Additionally, we need to decide how completely we'll conform, if at all, with the LSB in this area.</p>
+<p>Hopefully, this can get done by September 2012.</p>
 <h2 id="ma">Multiarch</h2>
 <p>Multiarch refers to the ability to install and use packages built for non-native architectures.  It is currently being <a href="http://wiki.debian.org/Multiarch">documented and implemented</a> 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).</p>
 <p>Simply speaking, there are six <a href="https://wiki.ubuntu.com/MultiarchSpec#Design">aspects of a multiarch implementation</a>:</p>
@@ -47,6 +48,7 @@
 <p>To be determined is how the "second stage" of the installation &ndash; the execution of package maintainer scripts (<code>preinst</code> and <code>postinst</code>) to complete the configuration of each package &ndash; 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.</p>
 <p>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.</p>
 <p>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.</p>
+<p>Hopefully, this tool can be done by October 2012.</p>
 <h2 id="pkg-x-build-tool">Package Cross Building Tool</h2>
 <p>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.</p>
 <h2 id="ma-x-toolchains">Multiarch Cross Toolchain Packages</h2>