[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Suggestions for --install
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2017-10-11 14:10:19
Message-ID: CAK1hOcPiv94HfPcn3C1A8gXJCHFOBjrFit=Pr_1Mn2M5fLBVdw () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 5, 2017 at 9:31 PM, Christoph Biedl
<busybox.cskc@manchmal.in-ulm.de> wrote:
> ... 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.

Let's just add this text unconditionally.

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

There is not.

 APPLET_INSTALL_LOC(applet_no) returns an integer, one of":
        BB_DIR_ROOT,
        BB_DIR_BIN,
        BB_DIR_SBIN,
        BB_DIR_USR_BIN,
        BB_DIR_USR_SBIN,

> * 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.

Please send a patch.

> * 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.

How about adding an "exclude" option:

busybox --install [-xDIR1:DIR2...] [-s] [DIR]

If applet matches existing file in any of those dirs,
then it is not installed.

The -xDIR parameter can be optional, defaulting to $PATH.

> * 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.

--list-full shows this information already.

Thanks!
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]