path: root/dev/todo/install-bb-without-bb.mdwn
diff options
Diffstat (limited to 'dev/todo/install-bb-without-bb.mdwn')
1 files changed, 38 insertions, 60 deletions
diff --git a/dev/todo/install-bb-without-bb.mdwn b/dev/todo/install-bb-without-bb.mdwn
index 55ae48c..ca71b6b 100644
--- a/dev/todo/install-bb-without-bb.mdwn
+++ b/dev/todo/install-bb-without-bb.mdwn
@@ -2,11 +2,11 @@
**or, Adventures in Regressions and Crazy Ideas**
-`opkg` and the Outsourced Inflation
+Two Problems
-The Problem
+`opkg` and the Outsourced Inflation
opkg-lede now [relies][opkg-lede-dd4c78a] on an external `gzip` executable.
When upgrading a package, it tries to execute `gzip` to unpack maintainer
@@ -17,26 +17,8 @@ package. When the package being upgraded is `busybox`, which provides `gzip`,
-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`.
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`.
@@ -50,40 +32,36 @@ can't be configured when first unpacked by `prokit`.
-A Non-Solution
-`busybox`'s `postinst` script doesn't (need to) execute any commands that aren't
-`ash` built-ins (`cat` is there but can be replaced with `read`), 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?
-Crazier idea: could solution 2 of the first problem above actually solve this
-problem? `busybox` would need to declare that it `Breaks` older versions of
-`opkg-lede`, to ensure a sufficiently new `opkg-lede` is installed to handle
-`busybox`'s alternatives madness. Also, the `opkg` wrapper itself would have to
-be careful to execute utilities as `busybox $util` (including `#!/bin/busybox
-sh`) at least until setting up the temporary directory and setting and exporting
+One Solution
+The next version of `src:opkg-lede` (likely 0+git20190131.d4ba162-7) already
+will have a [wrapper script called `opkg`][opkg] that executes `opkg-cl` (the
+actual binary executable). The script can be extended to first save a copy of
+`/bin/busybox` to an empty temporary directory, generate utility links to it in
+the directory, and add the directory to `PATH`. Until all of this setup is
+complete, the wrapper script must be careful to execute utilities as `busybox
+$util` (a full path to `busybox` won't be necessary, as the usual `/bin/busybox`
+will be available at that point). This includes the interpreter line, which
+will need to be changed to `#!/bin/busybox sh`. `ash` built-in utilities can be
+used as usual.
+The `busybox` package can't use `update-alternatives` to manage all of its
+utility links until an `opkg-lede` with this wrapper script functionality is
+uploaded. This is because, even if `busybox`'s `postinst` script is modified to
+use the `busybox` executable directly, other packages' maintainer scripts may be
+executed first, while `busybox` is unpacked but not yet configured (and
+therefore utility links are not yet created).
+Once this new `opkg-lede` package is uploaded and `busybox` uses
+`update-alternatives` for everything, `busybox` would need to declare that it
+`Breaks` older versions of `opkg-lede`, to ensure that `opkg-lede` will preserve
+a copy of the `busybox` executable and its utility links.
+The `opkg` script of the `opkg-lede` package will need to read `busybox`'s list
+of alternatives links. This is currently located at
+`/usr/share/busybox/alternatives`, though the file's format will change when
+`busybox` uses `update-alternatives` for everything. A migration strategy for
+`opkg-lede` will need to be designed.