From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit
Date: Tue, 28 Jan 2014 08:13:35 +0100 [thread overview]
Message-ID: <52E7589F.7060301@mind.be> (raw)
In-Reply-To: <CAPyrzo0q7Y3Tf1LOaCe4LK78a7sZrVdToLfnzp4Tc4kow=-nKA@mail.gmail.com>
On 03/01/14 20:41, Ivan Sergeev wrote:
> Currently, it seems that the /etc/init.d scripts are copied over blindly
> from the target skeleton to the target even if systemd (and not busybox)
> is the chosen init system. Moving forward, having both busybox and
> systemd init files in the skeleton, like this patch would have, will
> always clutter /etc/ with some unused init files in the target system,
> since only one init system will be active.
>
> Should such init files be conditional targets in system/system.mk
> ? Or should S40network be owned and copied over by
> package/busybox, and network.service be owned and copied over by
> package/systemd, instead of having them included statically in the target
> skeleton?
I completely agree that the way it is done now is far from ideal.
I think the best way to work with this would be to:
- remove the contents of the init.d directory from the skeleton;
- create a new skeleton fragment system/skeleton-init-sysv that contains
etc/init.d;
- create a new skeleton fragment system/skeleton-init-systemd that
contains whatever support files are needed by systemd (currently nothing,
but your patch would add the networking unit file);
- copy the correct skeleton fragment as part of the .root target, but
only if the default skeleton was selected - with a custom skeleton, it's
up to the user to provide the right systemd/init.d;
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2014-01-28 7:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 1:38 [Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit Ivan Sergeev
2014-01-03 19:13 ` Thomas Petazzoni
2014-01-03 19:41 ` Ivan Sergeev
2014-01-28 1:54 ` [Buildroot] [PATCH 1/1] systemd: add network unit file Ivan Sergeev
2014-06-11 20:34 ` Thomas Petazzoni
2014-06-13 15:42 ` Eric Le Bihan
2014-06-13 15:44 ` Thomas Petazzoni
2014-01-28 7:13 ` Arnout Vandecappelle [this message]
2014-01-28 8:25 ` [Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit Maxime Hadjinlian
2014-01-28 8:38 ` Arnout Vandecappelle
2014-01-28 13:20 ` Maxime Ripard
2014-01-28 17:20 ` Arnout Vandecappelle
2014-01-29 8:26 ` Maxime Ripard
2014-01-29 9:07 ` Maxime Hadjinlian
2014-01-29 9:09 ` 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=52E7589F.7060301@mind.be \
--to=arnout@mind.be \
--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.