From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/2] package/iputils: move binaries to the location also used by Busybox
Date: Tue, 18 Jun 2019 09:17:11 +0200 [thread overview]
Message-ID: <20190618091711.3b3ca1b8@windsurf> (raw)
In-Reply-To: <20190618065929.GC8350@x230>
Hello,
On Tue, 18 Jun 2019 08:59:29 +0200
Petr Vorel <petr.vorel@gmail.com> wrote:
> > Adjusting the Busybox configuration is not the choice we have made to
> > solve this problem. Instead, the way we have chosen to solve the
> > conflict between Busybox applets and the "full-blown" variant of the
> > same tools is by:
>
> > - Making "busybox" depend on all packages that provide the full-blown
> > variants, so that those full-blown variants are built/installed
> > before Busybox.
>
> > - Ensure the Busybox installation process does not overwrite the
> > full-blown variants when they are already installed.
>
> > This ensures that at the end of the build, if a full-blown variant is
> > installed, it takes precedence over the Busybox applet.
>
> > The drawback is while the Busybox symlink is not installed, the actual
> > code is present in the Busybox binary.
>
> Thanks for an explanation. Having a bit bigger binary it's not a big deal.
> If this is a problem for any reason, fortunately user can supply it's own
> busybox config.
> I guess you took this direction because it's much simpler than messing with
> busybox config (the solution I suggested).
Yes, that's exactly the reason. It would require to keep track of which
Busybox options need to be disabled, depending on which other Buildroot
packages/options are enabled.
That being said, the current solution also requires that all packages
install their programs in the same location as the corresponding
Busybox applets, which also requires some maintenance effort.
None of the solutions is perfect, and a trade-off has to be made.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2019-06-18 7:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-16 20:09 [Buildroot] [PATCH 1/2] package/iputils: move binaries to the location also used by Busybox Thomas Petazzoni
2019-06-16 20:09 ` [Buildroot] [PATCH 2/2] package/iputils: fix IPUTILS_PERMISSIONS Thomas Petazzoni
2019-06-17 20:32 ` Petr Vorel
2019-06-18 6:49 ` Thomas Petazzoni
2019-06-18 7:01 ` Petr Vorel
2019-06-16 20:20 ` [Buildroot] [PATCH 1/2] package/iputils: move binaries to the location also used by Busybox Yann E. MORIN
2019-06-17 17:31 ` Thomas Petazzoni
2019-06-17 20:24 ` Petr Vorel
2019-06-18 6:46 ` Thomas Petazzoni
2019-06-18 6:59 ` Petr Vorel
2019-06-18 7:17 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190618091711.3b3ca1b8@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox