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
next prev parent 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