diff options
| -rw-r--r-- | dev/todo/install-bb-without-bb.mdwn | 78 |
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? |