From e88faa7efb1862843a58682fd5da6c4c980236c3 Mon Sep 17 00:00:00 2001
From: P. J. McDermott <pjm@nac.net>
Date: Sat, 23 Jun 2012 02:14:28 -0400
Subject: Add task "Removing libbb from opkg" to /dev/todo.

---
diff --git a/dev.html b/dev.html
index b0e1713..a80d7c3 100755
--- a/dev.html
+++ b/dev.html
@@ -51,5 +51,7 @@
 	<dd>Packages of toolchain components that use multiarch library paths.</dd>
 	<dt><a href="todo#packaging">Packaging</a></dt>
 	<dd>Software that should be packaged soon.</dd>
+	<dt><a href="todo#opkg-libbb">Removing libbb from opkg</a></dt>
+	<dd>The modification of opkg to dynamically link against a newer libbusybox.</dd>
 </dl>
 <!--#include file="includes/footer.html" -->
diff --git a/dev/todo.html b/dev/todo.html
index a18da8a..9d6c3fa 100755
--- a/dev/todo.html
+++ b/dev/todo.html
@@ -110,4 +110,20 @@
 		<p>U-Boot is a bootloader used on many embedded computers, including the BeagleBoard-xM.</p>
 	</li>
 </ul>
+<h2 id="opkg-libbb">Removing libbb from opkg</h2>
+<p>opkg includes and is statically linked with <a href="https://code.google.com/p/opkg/source/browse/trunk/libbb">a copy of libbb</a>, 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.</p>
+<h4>The Good News</h4>
+<p>libbb can be built as a shared library by setting the <code>CONFIG_BUILD_LIBBUSYBOX</code> option to <code>y</code> in BusyBox's configuration.  So, we can make <code>libbusybox.N</code> and <code>libbusybox.N-dev</code> 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 <code>opkg</code> source package and its binary packages.</p>
+<h4>The Bad News</h4>
+<p>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, <a href="https://groups.google.com/group/opkg-devel/browse_thread/thread/fe5c620bc339ba63">an attempt</a> 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.</p>
+<p>To make matters slightly worse, many of the libbb files have been patched in opkg.  Any files in <a href="https://code.google.com/p/opkg/source/browse/trunk/libbb">/trunk/libbb</a> newer than revision 3 have opkg modifications.</p>
+<h4>The Plan</h4>
+<ul>
+	<li>Build a shared libbusybox library and set of binary packages.</li>
+	<li>Port opkg to work with more recent versions of BusyBox's shared library.</li>
+	<li>Modify opkg to dynamically link against libbusybox.</li>
+	<li>Add <code>Build-Depends</code> and <code>Depends</code> fields to the <code>opkg</code> source package.</li>
+	<li>Investigate API and ABI stability of libbusybox.  This may require coordination with BusyBox developers.</li>
+	<li>Look at each patch in opkg against libbb.  If it's still useful in newer versions, then refresh it, apply it to the <code>busybox</code> source package, and forward it upstream to BusyBox.<li>
+</ul>
 <!--#include virtual="../includes/footer.html" -->
--
cgit v0.9.1