1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
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?
|