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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox