Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] issues without busybox
Date: Mon, 21 Jul 2014 22:15:55 +0200	[thread overview]
Message-ID: <20140721221555.72df12ca@free-electrons.com> (raw)
In-Reply-To: <98386AE2-7424-4E70-8839-6B642B9938F4@whospot.com>

Dear Gilles,

On Mon, 21 Jul 2014 12:57:50 -0700, Gilles wrote:

> Buildroot is a fantastic effort for small footprint devices. However,
> in my case - where I'd rather have something a bit more SystemV like
> with MMU, no busybox, a lot of things are broken.
> 
> Just naming a few I recently fixed to get past some issues:
> 
> - init network script S40network which tries to use ifup/ifdown only
> provided in ifupdown package not included.
> - S45connman sript (if used) which relies on start-stop-daemon only
> provided with dpkg.
> 
> I understand that dependencies quickly add up to a nightmare and I
> for one would agree that it should be left up to the user of
> buildroot to figure them out.
> 
> What is the buildroot community feeling about this subject? I
> understand that the main focus is on busybox, is there a group of
> people interested in the non-busybox approach? I would be willing to
> contribute, after all, I have to do this work right now to get me up
> and going. This might benefit other people.

Thanks a lot for reporting those issues. Patches are definitely welcome
to fix this.

I believe one direction we should potentially investigate is to have
one common skeleton for the base stuff, and then separate additional
skeletons for busybox init, sysv init and systemd init.

Regarding the specific issues you're raising here, I'm not exactly sure
how to solve them:

 * For the network, we could make sysvinit depend on ifupdown, but this
   sounds a bit strong. Then it would mean that we should make the init
   script installation conditional. Or maybe installed just by ifupdown
   on one side, and busybox on the other side?

 * Regarding start-stop-daemon, I believe all (most?) our init scripts
   rely on start-stop-daemon. So I'm not sure how to handle that...

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2014-07-21 20:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 19:57 [Buildroot] issues without busybox Gilles
2014-07-21 20:15 ` Thomas Petazzoni [this message]
2014-07-21 20:28   ` Gustavo Zacarias
2014-07-21 21:35     ` Gilles
2014-07-22 10:31       ` Gustavo Zacarias
2014-07-22 12:17     ` Eric Le Bihan
2014-07-22 12:34       ` Gustavo Zacarias
2014-07-25 11:00 ` Peter Korsgaard

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=20140721221555.72df12ca@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.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