All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <petr.vorel@gmail.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 08:59:29 +0200	[thread overview]
Message-ID: <20190618065929.GC8350@x230> (raw)
In-Reply-To: <20190618084657.64bd21e4@windsurf>

Hi Thomas,

> Hello Petr,

> Thanks for the feedback.

> On Mon, 17 Jun 2019 22:24:03 +0200
> Petr Vorel <petr.vorel@gmail.com> wrote:

> > > iputils installs several programs that are also implemented as applets
> > > in Busybox. Two of these (arping and tftpd) are installed by iputils
> > > in /bin, while Busybox installs them in /usr/sbin, causing both to be  
> >      ^
> > I guess you mean /usr/bin

> Gah, indeed. Unfortunately, the v2 of my patch has already been applied
> by Arnout, and it has the same issue.
Yes, I've noticed yesterday after sending review :).
But this is just a tiny detail.

> > Although I'm not keen on changing binary default location,
> > this is simple straightforward solution. Alternative would be to disable busybox
> > config CONFIG_ARPING (with support/kconfig/merge_config.sh), but that'd be too
> > complicated. Thus ack

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

> > Just small research about iputils install directories.
> > busybox keeps mixed dirs /usr/{s,}bin and /{s,}bin (locations which were before
> > usrmerge concept), ping is indeed in /bin [1].
> > Debian chose also mixing /usr/{s,}bin and /{s,}bin [2]

> > But I'm concern about /{usr/,}/bin vs. /{usr/,}/sbin.
> > iputils before starting to use  meson didn't have any default location.
> > There was iputils.spec file [3] (now deleted), which suggested some locations,
> > but was marked as for testing purposes only. It had different paths than busybox
> > and Debian use. I guess I have to accept that there was no consensus and
> > therefore are differences in paths across both upstreams and distros.

> Due to the way we handle the Busybox applet vs. full-blown variant
> conflict (detailed above), we really need the full-blown variant to be
> installed at the same location as the corresponding Busybox applet.
Understand.

> Thomas

Kind regards,
Petr

  reply	other threads:[~2019-06-18  6:59 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 [this message]
2019-06-18  7:17       ` Thomas Petazzoni

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=20190618065929.GC8350@x230 \
    --to=petr.vorel@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.