[Buildroot] [PATCH 1/1] skeleton: add systemd network.service unit

Maxime Hadjinlian maxime.hadjinlian at gmail.com
Tue Jan 28 08:25:20 UTC 2014


Hi all

On Tue, Jan 28, 2014 at 8:13 AM, Arnout Vandecappelle <arnout at mind.be> wrote:
> 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;
I  agree with you and as a matter of fact, I had already started
working on a patch that implement exactly this.

I would even like to go even further, as I have noticed that a lot of
the defined LIBFOO_INSTALL_INIT_SYSTEMD and LIBFOO_INSTALL_INIT_SYSV
almost always do the exact same stuff.
I would like for the infrastructure to take care of this, if no
function is defined, and a .service or S\d{0,2}*, then we should take
it and install it.

In that case, any particular requirements, the package define a
function, other than that, it's taken care of and we avoid duplicate
code in all the packages.

>
>
>
>  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
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


More information about the buildroot mailing list