dev/todo/install-bb-without-bb: New article

1 files changed, 78 insertions, 0 deletions

diff --git a/dev/todo/install-bb-without-bb.mdwn b/dev/todo/install-bb-without-bb.mdwn
new file mode 100644
index 0000000..7ae8f7c
--- /dev/null
+++ b/dev/todo/install-bb-without-bb.mdwn
@@ -0,0 +1,78 @@
+[[!meta title="Installing BusyBox Without BusyBox"]]
+
+**or, Adventures in Regressions and Crazy Ideas**
+
+`opkg` and the Outsourced Inflation
+===================================
+
+The Problem
+-----------
+
+opkg-lede now [relies][opkg-lede-dd4c78a] on an external `gzip` executable.
+When upgrading a package, it tries to execute `gzip` to unpack maintainer
+scripts and data files [after][opkg_install_pkg] removing the old version of the
+package.  When the package being upgraded is `busybox`, which provides `gzip`,
+`opkg` crashes and leaves behind a completely broken system.
+
+[opkg-lede-dd4c78a]: https://git.openwrt.org/?p=project/opkg-lede.git;a=commitdiff;h=dd4c78aa88efd3b9cf516030937c684814df7962
+[opkg_install_pkg]: https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/opkg_install.c;hb=d4ba162#l1520
+
+Possible Solutions
+------------------
+
+A wrapper script that calls `opkg-cl` (the actual binary executable) needs to
+save a copy of `/bin/busybox` which `opkg-cl` can execute as `gzip`.
+
+**Solution 1:**  `opkg-cl`'s [`gzip_exec()`][gzip_exec] is patched to execute
+the absolute path of the `busybox` copy as `gzip`.
+
+**Solution 2:**  The wrapper copies `/bin/busybox` to an empty directory and
+either names the copy `gzip` or generates links to it.  It then runs `opkg-cl`
+with the (temporary) directory in `PATH`.
+
+[gzip_exec]: https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libbb/gzip.c;hb=d4ba162#l70
+
+The Amazing Alternatives of `busybox`
+=====================================
+
+The Problem
+-----------
+
+Instead of adding alternatives one at a time, [it would be nice][bb-ua] to
+manage all of `busybox`'s utility links using `update-alternatives`.
+Unfortunately, the maintainer script that runs `update-alternatives` (as well as
+the `update-alternatives` script itself) needs a few `busybox` utilities
+(`/bin/sh` for a start).  Thus, after an older version of `busybox` is
+deconfigured, a newer version can't be configured.  `busybox` also can't be
+configured when first unpacked by `prokit`.
+
+[bb-ua]: http://git.proteanos.com/pkg/busybox.git/commit/?id=1558d05c62ed90f7d93a14533541c33896b7b733
+
+A Non-Solution
+--------------
+
+`busybox`'s `postinst` script doesn't execute any commands that aren't `ash`
+built-ins, but it will need to have its interpreter line changed from
+`#!/bin/sh` to `#!/bin/busybox sh`.  `update-alternatives` will need to be
+modified (rewritten?) to execute `busybox` directly.
+
+However, there are at least two problems with this approach.
+
+When installing a system, `busybox` won't necessarily be the first package to be
+configured.  Other maintainer scripts may be executed before `busybox`'s
+`postinst` is able to create the utility links they need.
+
+Additionally, foreign-architecture system installations aren't configured at
+install time.  Instead, they need to be able to at least boot far enough to run
+`opkg install $(opkg list-installed | cut -d " " -f 1)`, which, again as above,
+may run other maintainer scripts before `busybox`'s `postinst`.
+
+Another possible solution is to add special-case code to `prokit` to create
+`busybox`'s links between unpacking and configuring, but that further opens the
+can of worms that is compatibility between versions of `prokit` and the
+distribution it installs.
+
+The End?
+--------
+
+Perhaps this idea is too crazy?