Suggestions for --install

Christoph Biedl busybox.cskc at manchmal.in-ulm.de
Thu Oct 5 19:31:57 UTC 2017


Hello there,

a quite belate hello from the second guy doing busybox packaging for
Debian. Some things have piled up over time, I'll bring them here when
it seems appropriate. For a start, a few issues related to the
--install option.

* Missing documention (Debian#653259)

There is no documentation for the --install option in the manpage.

While that's not a big deal to add a text (feel free to borrow) like ...

    --install [-s] [<target>]

    Will create hard links or symlinks for all the applets that are
    compiled into busybox.

    If the "-s" option is given, will create symlinks instead of
    hardlinks.

    If a target directory is provided, all links will be created
    there. By default, busybox will install them in /bin/, /usr/bin/, or
    similiar places, depending on each plugin's configuration.

    An existing target will not be touched.

... the (for me) awkward part is to embed this into the manpage if and
only if CONFIG_FEATURE_INSTALLER is set. This is still somewhat beyond
my knowledge of the busybox build and install system. Don't get me
wrong, it's highly evolved and appropriate for its purpose - just a lot
of layers¹ to work through in order to understand it, this will take
some more time.

¹ For example, is there an explanation for APPLET_INSTALL_LOC around?

* Unhandy installation path for readlink (Debian#801850)

The readlink applet (and some more like bzip2) gets installed into
/usr/bin/ - while in Debian the full-feature readlink provided by
coreutils is in /bin/. Therefore, --install will happily install a
/usr/bin/readlink link which then has precedence in PATH, thus
shadowing the coreutils version, possibly breaking applications that
rely on the latter.

It might be an idea to change the installation path for these applets.
If you (upstream) think this is a Debian specific problem, it's not an
issue for me to do this in Debian only.

Besides, it seems the major distributions will merge the four
executable directories /{usr/,}{,s}bin will into a single only in the
long run, rendering the whole issue void. But we're not there yet.

* More options 1: --pre-check (Debian#801850 again)

To mitigate the above issue, there was a suggestion to install a
busybox applet link only if that executable is not availabe yet, or in
other words: After a base installation, use busybox --install to fill
the remaining gaps only.

For this, busybox would have to check for each applet whether that
particular one is already available. Calling "which" many times
will result in a performance penalty but --install doesn't get
called that often anyway.

Depending on the default behaviour that option might be called
--force (skip check) as well.

* More options 2: --dry-run

It might be desirable to learn where --install (without a target
directory) will create the link for each applet without actually doing
anything. For this, a "dry run"/"no activity" option was a nice thing
to have. Using that option was also a way to learn where a particular
plugin link will be installed by default.


Finally, in the intention to actually improve busybox and not to appear
just demanding: I am willing to write according patches, just give me a
basic acknowledgment for these ideas.

    Christoph


More information about the busybox mailing list